I had a gitlab job defined as follows.
test-1:
stage: test
only:
variables:
- $RUN_TEST
except:
- tags
and then I changed that job to run based on gitlab rules.
test-1:
stage: test
rules:
- if: '$CI_PIPELINE_SOURCE != "schedule" && $CI_COMMIT_TAG == null'
- if: '$RUN_TESTS == "true" && $CI_COMMIT_TAG == null'
After this change, Whenever I commit some change to my branch, I am getting two pipeline runs in my gitlab project. One is for the latest commit I have made and second as detached.
How can I get rid of detached pipeline run?
Another interesting thing is, when I cancel the latest pipeline the detach pipeline also got cancelled.
For latest pipeline, value of CI_PIPELINE_SOURCE = push and for detach pipeline, value of CI_PIPELINE_SOURCE = merge_request_event.
The detached pipelines you are seeing are merge request pipelines. You can use workflow:rules to control when a pipeline is created. To prevent merge request pipelines:
workflow:
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
when: never
- when: always
Related
I'm trying to trigger a gitlab pipeline only after the merge request is actually merged, only for merge requests, and only if it comes from the 'Develpment' branch.
For that I'm using this rule:
rules:
- if: '$CI_COMMIT_REF_NAME == "Production"'
when: manual
- if: '$CI_MERGE_REQUEST_EVENT_TYPE == "merged_result" && $CI_COMMIT_REF_NAME == "Development"'
when: on_success
However, it seems to be running on any commit to the branch Development...
While developing gitlab ci-cd pipeline i want to run pipeline manually for a particular branch for example branch name is "develop-tool". what i want is anything done on this branch should not trigger pipeline automatically. it should be manually. what i have tried is:
workflow:
rules:
- when: manual # Error: workflow:rules:rule when unknown value: manual
then i tried to do this:
- if: '$CI_PIPELINE_SOURCE == "web" && $CI_COMMIT_REF_NAME !~ /^.*-$develop-tool/'
- when: always
its taking job to some infinite loop and it keeps running until and unless you cancel it and run the job again. does anyone have any other way to achieve this goal.
Have the configuration skip pipelines when the source is not the web for that branch. So the only way it can be triggered on that branch is through the web UI.
workflow:
rules:
- if: '$CI_COMMIT_BRANCH == "develop-tool" && $CI_PIPELINE_SOURCE != "web"'
when: never
- when: always
I want to see sonar results in the MR(merge request) command section when I create a MR.
My main expectations:
if there is an existing MR for the source branch, trigger detached pipeline (do not trigger feature pipeline. I need only that one for reviewing sonar results in MR commands)
if there isn't an existing MR for the source branch, just trigger the normal feature(source) branch pipeline
I tried to do it with the below example stage. But when I pushed the commit to the source pipeline, while MR is exist for source branch. I still getting double pipeline. Detach and source pipelines are running and I don't want to see both in same time, plus except not working with rules configuration. How can I integrate except section with rules part.
This is my gitlab-ci stage:
deploy:
stage: deployment
when: manual
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event" && $CUSTOM_VARIABLE == "true" || $CUSTOM_VARIABLE == "true"'
script:
- ....
- ....
except:
- tags
- main
I also tried below rules, if one of them fit my condition don't run the other one. But it still trigger both pipelines.
deploy:
stage: deployment
when: manual
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event" && $CUSTOM_VARIABLE == "true"'
when: on_success
- if: '$CI_PIPELINE_SOURCE == "push" && $CUSTOM_VARIABLE == "true"'
when: on_success
script:
- ....
- ....
except:
- tags
- main
Covered in workflow:rules templates, In this case, you can use the CI_OPEN_MERGE_REQUESTS variable to determine whether to run the pipeline for merge request or just the feature branch.
If you use both [pipelines for merge requests and branch pipelines], duplicate pipelines might run at the same time. To prevent duplicate pipelines, use the CI_OPEN_MERGE_REQUESTS variable.
Using workflow:rules you can do this for the entire pipeline, but the same principle can also be applied to individual jobs.
workflow:
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
- if: '$CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS'
when: never
- if: '$CI_COMMIT_BRANCH'
This means your pipeline will run:
for merge requests
for branch pipelines UNLESS there is an open merge requests
Imagine a simple .gitlab-ci.yml file with the following
stages:
- test
- build
test_job:
stage: test
rules:
- if: '$CI_COMMIT_BRANCH && $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH'
script:
- exit 1
build_job:
stage: build
rules:
- if: '$CI_COMMIT_BRANCH && $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH'
changes:
- web-app/**/*
script:
- echo "Building..."
The first time this pipeline is run, you will see both jobs, however the build_job will not be run because the test_job failed (exit 1).
Correcting the exit 1 (to exit 0, for example) and re-running, you will now only see the test_job because to gitlab, the web-app files havent changed, yet they havent successfully run previously.
So how do you ensure the build_job is run to success??
In the scenario you described, your second commit contains only 1 change to your .gitlab-ci.yml file, therefore your changes: rule correctly causes the build_job to be excluded from the pipeline as you have configured the pipeline.
For branch pipelines, GitLab will not consider previous commits when evaluating the changes: rules.
However, with pipelines for merge requests, all changes in the merge request are tested. Which sounds like the behavior you are expecting.
If your goal is for efficient pipelines tracking your features branches, your best course(s) of action might be something like this:
Always run the build job on branch pipelines
Only apply the changes: rule for pipelines for merge requests
Optionally, exclude branch pipelines when an MR is open
Optionally, adopt a workflow whereby which you open (draft) merge requests when creating your feature branches
An optimized CI configuration that does not skip build job on branches may look like this:
build_job:
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
changes: # in the case of merge requests, we can be more efficient
- web-app/**/*
- if: '$CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS'
when: never # skip branch pipelines when MR pipelines exist
- if: '$CI_COMMIT_BRANCH' # but in branch pipelines, build every time
I have a gitlab pipeline where there are two stages, one is build and the other one is deploy. The build stage is run when a commit is made. I want a way to run the deploy job when the merge request is merged to master. I tried several things but no luck. Can anyone help?
stages:
- build
- deploy
dotnet:
script: "echo This builds!"
stage: build
production:
script: "echo This deploys!"
stage: deploy
only:
refs:
- master
Try using the gitlab-ci.yml "rules" feature to check for the merge request event.
Your current gitlab-ci.yml will run your "dotnet" job every commit, merge request, schedule, and manually triggered pipeline.
https://docs.gitlab.com/ee/ci/yaml/#workflowrules
dotnet:
script: "echo This builds!"
stage: build
rules:
- if: '$CI_COMMIT_REF_NAME != "master" && $CI_PIPELINE_SOURCE == "push" || $CI_PIPELINE_SOURCE == "merge_request_event"'
production:
script: "echo This deploys!"
stage: deploy
rules:
- if: '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_REF_NAME == "master"'
If you want your job run on only after merging the merge request, then you can trigger a job based on the commit message, as shown below.
rules:
- if: '$CI_COMMIT_MESSAGE =~ /See merge request/'
Basically, all the merge request comes with a "See merge request" commit message so you can depend on that message to trigger your job.
You can run the pipeline after merge by using Gitlab ci predefined variable $CI_MERGE_REQUEST_APPROVED this will return true after merge and available from gitlab v14.1.
If you want to run the pipeline when merge request is created to main branch you can use $CI_MERGE_REQUEST_TARGET_BRANCH_NAME with $CI_MERGE_REQUEST_APPROVED.
you can add the rule like this in your job.
rules:
- if: $CI_MERGE_REQUEST_APPROVED && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "main"
CI_MERGE_REQUEST_APPROVED variable seems to be designed for check approve status, not for triggering pipeline. (Issue, https://gitlab.com/gitlab-org/gitlab/-/issues/375908)
When you use merge request predefined variables, gitlab creates pipeline at merge request created, not at merge request approved.
Instead, use CI_COMMIT_BRANCH predefined variables with regular expression and restrict commit at master branch using branch access rights.
stages:
- build
- deploy
dotnet:
stage: build
rules:
- if: $CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == "master"
script: "echo This builds!"
production:
stage: deploy
rules:
- if: $CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == "master"
script: "echo This deploys!"
Edit answer for incorrect example. (edited at 2023. 01. 26)
Assume that we have rc and master branch.
We can configure master branch as protected, and use only for merge request.
In this case, we can define gitlab-ci file like below.
stages:
- build
- deploy
dotnet:
stage: build
rules:
- if: $CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == "rc"
script: "echo This builds!"
production:
stage: deploy
rules:
- if: $CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == "master"
script: "echo This deploys!"
Thanks for notification #Kappacake