I got two branches in my GitLab repo (uat and production). Two deploy jobs are meant to deploy a branch to a specific environment. There are two gitlab-ci.yml files, one in each branch (with the config for that branch) and production is my default branch.
The jobs should run only if files in dir/ changed and not for scheduled pipelines.
Problem: The deploy job for UAT is just working as expected: it runs if I push directly to the branch or if I accept a merge request. However, although there is no difference except the branch, the deploy job for production is not triggered on any event.
Question: Do you know if I misunderstood something and what would fix this?
Thanks!
gitlab-ci.yml in production
deploy_to_production:
only:
refs:
- production
changes:
- dir/*
except:
- schedules
script:
# upload to prod
gitlab-ci.yml in uat
deploy_to_uat:
only:
refs:
- uat
changes:
- dir/*
except:
- schedules
script:
# upload to uat
Do you have those empty lines before script: in your file?
This will define script under default, because it is not tied to a job.
default:
script:
# upload to uat
The reason that it is only running uat is that on the second reference the first one gets overwritten. You can check this on gitlab on your project page under CI/CD/Editor.
And here you can view the final yaml after merging:
Related
I have repository in GitLab. and I have Test and Dev branches in this repository.
In Gitlab pipeline, I schedule a job to auto run Test branch pipeline every 24 hours.
in Test .gitlab-ci.yml I have
deploy:
stage: deploy
script:
- git pull --ff-only origin Dev
only:
- Test
After merging Dev in Test, this part of code was removed. And next time Test branch pipeline could not pull from Dev branch, when pipeline run.
How can I pull code from Dev branch to Test Branch without losing the code - git pull --ff-only origin Dev ?
Or maybe it is possible to have tow .gitlab-ci.yml on branch? (if yes, how GitLab should know which one of them be diploid first? )
Or maybe it is possible to have two .gitlab-ci.yml on branch
You would generally create your .gitlab-ci.yml in the main/master branch.
Which means that .gitlab-ci.yml would not be impacted by merges between Test and Dev. Which is what you need.
I am working on a multi-pipeline project, and using trigger keyword to trigger a downstream pipeline, but I'm not able to pass artifacts created in the upstream project. I am using needs to get the artifact like so:
Downstream Pipeline block to get artifacts:
needs:
- project: workspace/build
job: build
ref: master
artifacts: true
Upstream Pipeline block to trigger:
build:
stage: build
artifacts:
paths:
- ./policies
expire_in: 2h
only:
- master
script:
- echo 'Test'
allow_failure: false
triggerUpstream:
stage: deploy
only:
- master
trigger:
project: workspace/deploy
But I am getting the following error:
This job depends on other jobs with expired/erased artifacts:
I'm not sure what's wrong.
Looks like there is a problem sharing artifacts between pipelines as well as between projects. It is known bug and has been reported here:
https://gitlab.com/gitlab-org/gitlab/-/issues/228586
You can find a workaround there but since it needs to add access token to project it is not the best solution.
Your upstream pipeline job "Build" is set to only store its artifacts for 2 hours (from the expire_in: 2h line. Your downstream pipeline must have run at least 2 hours later than the artifacts were created, so the artifact expired and was erased, generating that error.
To solve it you can either update the expire_in field to however long you need them to be active (so for example if you know the downstream pipeline will run up to 5 days later, set it to 5d for 5 days), or rerun the Build job to recreate the artifacts.
You can read more about the expire_in keyword and artifacts in general from the docs
It isn't a problem with expired artifacts, the error is incorrect. In my case I am able to download the artifacts as a zip directly from the UI on the executed job. My expire_in is set to 1 week yet I am still getting this message.
We create new branches from develop branch that starts with hotfix/bla_bla or feature/bla_bla. Then, we merge them back into develop branch. On merge requests, I would like to run a job only when we merge feature branches into develop branch. Something like:
job:
stage: test
only:
refs:
- develop && "when a branch which starts with 'feature/' is merged into develop"
How could I achieve this in .gitlab-ci.yml file or using a .sh file?
Untested, but you potentially can use a combination of pipelines for merge requests and the CI Variable CI_MERGE_REQUEST_SOURCE_BRANCH_NAME.
For example, something like:
job:
stage: test
only:
refs:
- merge_requests
- develop
variables:
- $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME == "feature/*"
The CI pipeline runs on every commit in my Gitlab repository at work. Is there way to disable that and only run the CI pipeline on an open merge request to the master branch?
There is currently no configuration option to do that. Here are some things that can be used to "disable" a pipeline build.
Adding [ci skip] inside the commit message will not trigger a pipeline on push.
Using except and only options on all jobs inside the pipeline. To avoid duplication in this case, you can use Anchors.
Update: GitLab 11.7
When pushing to GitLab you can skip triggering a pipeline by passing ci.skip option to the push command: git push -o ci.skip
Update in 2020 because solution with only and except are candidates for deprecation : https://docs.gitlab.com/ee/ci/yaml/#onlyexcept-basic
Still in .gitlab-ci.yml you should use now rules : See https://docs.gitlab.com/ee/ci/yaml/#rules
I simply set this rule on my build job and the job is "blocked" and wait a manual trigger from the UI.
rules:
- when: manual
Note that we can create more advanced rules with conditions to trigger for exemple if we see a git tag.
https://docs.gitlab.com/ee/ci/yaml/#exclude-jobs-with-rules-from-certain-pipelines
Yes, but only if you set it on each job within the pipeline.
https://docs.gitlab.com/ee/ci/yaml/#onlyexcept-basic
job:
script: echo 'test'
only:
- merge_requests
That job will only run on commits that are part of a merge request, rather than every push of a commit to a branch. If you set every job to this setting then the pipeline will never run.
You can just add [ci skip] to the commit message and builds will be skipped
https://gitlab.com/gitlab-org/gitlab-ce/issues/14499
You could add something like this in the beginning of your .gitlab-ci.yaml
workflow:
rules:
- if: "$CI_COMMIT_BRANCH"
when: never
- if: '$CI_PIPELINE_SOURCE == "merge_request_event" && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"'
For more info look at Merge request pipelines
No. (Not yet !)
You can follow the expected feature development here.
https://gitlab.com/gitlab-org/gitlab-ce/issues/23902
However, you can automatically trigger pipelines using "maofr"'s code
https://gitlab.com/gitlab-org/gitlab-ce/issues/23902#note_88958643
For merge we can use this guide #onlyrefs--exceptrefs
merge_requests
For pipelines created when a merge request is created or updated. Enables merge request pipelines, merged results pipelines, and merge trains.
and for generally triggering pipeline we can use only: and variables: together:
script:
- . diff.sh $SMS_MESSAGE
only:
variables:
- $ACTION == "diff"
then triggering it is easy using curl:
curl -X POST \
-F token=$TOKEN \ # your token
-F ref=$REF_NAME \ # branch name
-F "variables[ACTION]=diff" \ # variable
https://gitlab.com/api/v4/projects/0/trigger/pipeline # your project endpoint
This part variables[ACTION]=diff will assign diff into ACTION and it will apply to .gitlab-ci.yml and only: section.
job:
stage: build
script:
- echo "Do your build here"
except:
- pushes
Use except pushes to stop create a new pipeline on every pushed commits. For reference check this
Update 2022 :
According to the documention of Gitlab on: https://docs.gitlab.com/ee/ci/yaml/#when
you can use when: manual to run the job only when triggered manually.
Example:
deploy_job:
stage: deploy
script:
- make deploy
when: manual
You don't need also rules for that.
I am currently having my project in GitLab and Heroku. What I wanna do is as soon as I ask for merge request with my feature branch (let's call it crud-on-spaghetti), I want to automatically run the tests on this branch (npm test basically, using Mocha/Chai), and after they succeed, merge this crud-on-spaghetti with master, commit it and push it to origin/master (which is remote on GitLab) and after git push heroku master (basically, push it to the master branch in Heroku, where my app is stored). I have read several articles on GitLab CI and I think this is more suitable for me (rather than Heroku CI, because I do not have DEV and PROD instances).
So, as of now, I do this manually. And this is my .gitlab-ci.yml file now (which is not committed/pushed yet):
stages:
- test
- deploy
test_for_illegal_bugs:
stage: test
script:
- npm test
deploy_to_dev:
stage: deploy
only:
- origin master
script:
- git commit
- git push origin master
- git pull heroku master --rebase
- git push heroku master
Hence, my questions is: What do I exactly need to write in .gitlab-ci.yml in order to automate all these "manipulations" (above)?
PS. And another (theoretical) follow-up question: how is GitLab-CI Runner triggered? For instance, if I want it to trigger upon merge request with master, do I do that using only: ... in .gitlab-ci.yml?
Restrict stages to Merge Requests:
To have your test stage only being executed when a Merge Request (MR) is opened, use
only:
- merge_requests
According to the Gitlab docs, you can further restrict this to only being executed for MRs with a certain target branch, e.g. only MRs for master
only:
- merge_requests
except:
variables:
- $CI_MERGE_REQUEST_TARGET_BRANCH_NAME != "master"
This adds an exception for all target branches that are not master.
Or use rules: for that:
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event" && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"'
Restrict stages to Branches:
As already mentioned by #marcolz, this is achieved by
only:
- master
to only execute the stage for pushes to the master branch.
Try
only:
- master
origin is just a name for a remote. master is the name of the branch.
The runner is triggered by GitLab-CI the moment that a commit is pushed to the repository, so alas not upon merge request.
You can use a trigger to trigger a pipeline and then call that trigger from a merge request event in integrations.