I am including a remote .gitlab-ci.yml file
variables:
ENTITY_NAME: $CI_PROJECT_TITLE
include:
remote: 'https://gitlab.com/paulblart/paul_test/-/main/.gitlab-ci.yml'
but checking for it YAML syntax in CI Lint GUI its saying
Included file 'https://gitlab.com/paulblart/paul_test/-/main/.gitlab-ci.yml' does not have valid YAML syntax!
But upon checking the syntax of .gitlab-ci.yml of the remote file its valid. I am not sure whats going on.
I saw a different version of problem in my case, I was trying to set CI/CD configuration file pointing to a different project with relatively longer name of a valid yaml file. I checked the linting, file was yaml but error thrown while attempting to run the pipeline was:
Included file .gitlab-ci-a-very-long-gilabci-file.yml#group/subgroup/pipeline-project does not have YAML extension!
Shortening the name solved it, Gitlab can improve the error messages.
Just adding as I didn't find it on Stackoverflow.
I have workaround for this issue
include:
- project: "my-project-with-yml/project-name"
ref: master
file: "/yml/.gitlab-ci.yaml"
rules: ## Optional, to show the support to **rules**
- if: $variable == "condition "
I was also facing the issue with YAML Error, even though the lint was green.
I had this error come up when I was trying to access a gitlab group which wasn't public, so I didn't have rights to look at the file.
Very uninformative error in that case.
Related
Artifacts is not uploaded after successful test pipeline. What's wrong with the code below?
Here's the result:
You are using a variable in your artefact name, which is currently not supported. As artifacts section is a separate post-script behaviour, your Test step is perfectly green.
To solve the issue, use a constant name for your artefact. Alternatively, you can combine the packaging and deployment steps into a single one:
script:
- echo "Packaging and deploying to test environment"
- zip -r example-$BITBUCKET_BUILD_NUMBER.zip .
- pipe: ...
This advice works https://stackoverflow.com/a/72570848/14740671 but I need to separate the deployment. I also tried uploading the file using this code:
- pipe: atlassian/bitbucket-upload-file:0.3.2
variables:
BITBUCKET_USERNAME: $BITBUCKET_UPLOAD_USERNAME
BITBUCKET_APP_PASSWORD: $BITBUCKET_UPLOAD_PWD
FILENAME: "example-1.zip"
It has no errors but file is still no seen in the Artifacts and azure deployments has "FileNotFoundError: [Errno 2] No such file or directory: '/opt/atlassian/pipelines/agent/build/example-1.zip'"
I've been working on getting a .gitlab-ci.yml pipeline to work but cannot find where the logs go.
GitLab.com message tells me
npm ERR! /root/.npm/_logs/2022-05-06T09_39_43_597Z-debug.log
I do not see this folder created on my project within GitLab.com so where and how do I get to the log?
After 51 iterations I have made a little bit of progress. 1st time seeing Green.
You could use artifacts to keep the log file, if the job fails. For example:
my job:
...
artifacts:
paths:
- "*.log"
when: on_failure
I'm not sure the paths pattern is correct. So, perhaps, it is neccessary to use **/*.log instead of *.log. But I hope, the idea is clear.
That can be seen by adding debug logging to your .gitlab-ci.yml file.Once you add it ,run the job again and you can get a detailed log
In my .gitlab-ci.yml i'm trying to deploy on merge request.
My pipeline works, script is executed , everything is ok and running , but i'm not able to read any predefined environment variables. My files looks like :
executeAutomationTests:
stage: check
only:
refs:
- merge_requests
script:
- echo $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME
But $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME is not resolved. I need to know source branch for the merge_request in order to pull the code and make a deployment. I have tried other variables like : $CI_COMMIT_REF_NAME, $CI_JOB_STAGE , but non of them are resolved.
My GitLab version : GitLab Community Edition 13.4.2
The problem was that in the pipeline job monitor the variable wasn't resolved and that's confused me. It was looking like :
So, for anyone who is fighting with such things, keep that in mind and also, keep in mind differences in syntax between powershell , bash and so on ..
Trying to check my .gitlab-ci.yml for errors and discovered this through the CI Lint in CI/CD section. The following section throws syntax incorrect even though it's according to https://my.gitlab-instance/help/ci/environments
environment:
name: staging
url: https://staging.example.com
Produces this lint error:
Status: syntax is incorrect
Error: jobs:environment config contains unknown keys: name, url
Even trying to hack away with adding dashes like this
environment:
- name: staging
- url: https://staging.example.com
Which gives this instead
Status: syntax is incorrect
Error: jobs:environment config should be a hash
Any ideas how to do this correct?
The team updated Gitlab instance to latest version and the lint error have since disappeared. No idea if this was the actual fix to the lint error but seemed to be working since then.
It's been 2 days since one of my project' build starts failing on Gitlab CI. The main error was E_MISSING_APP_KEY and when I check another variable just by echoing $HOST and $PORT from my .gitlab-ci.yml config, like this
tests:
script:
- echo "${HOST} ${PORT}"
- node -e "console.log(process.env.HOST, process.env.PORT)"
- node_modules/.bin/nyc node ace test -t 0
I got nothing.
The build was failed because it can't read my environment variable that I set on its CI Settings.
Anyone experiencing same issue? & how to solve this?
Update:
I'm trying to create new project with only containing .gitlab-ci.yml file here and it's seems working just fine
But why the world it's still failing on my main project?
For anyone else having a similar problem:
check your variable, if it is protected your branch has to be protected as well or remove the protected option on your variable
The issue is solved by delete all of my variables I've had & set them back from the CI Setting. And the build pipeline is running without any errors. (except the actual testing is still failed, lol)
Honestly, I'm still wondering why this could happened? and hopefully no one will experiencing same kind of issue like me here..