Trying to model a job that runs automatically for tags and manually for specific branches using rules. However the job is always triggered without user intervention
ismanual:
stage: prepare
rules:
# Always deliver a tagged build
- if: '$CI_COMMIT_TAG != ""'
when: on_success
# Manual deliver a feature branch build
- if: '$CI_COMMIT_BRANCH =~ /feature\/.*/'
when: manual
script:
- echo "hello"
I'm using gitlab.com!
You need to change your check for commit tags. In a rules clause you can check for a variable like below, so no need to compare it to an empty string.
ismanual:
stage: prepare
rules:
# Always deliver a tagged build
- if: '$CI_COMMIT_TAG'
# Manual deliver a feature branch build
- if: '$CI_COMMIT_BRANCH =~ /feature\/.*/'
when: manual
script:
- echo "hello"
Related
When I run following Gitlab CI, it invokes duplicate for both jobs(i.e 4 pipelines). What I need here is to invoke only one job if the condition qualifies
default:
image: 'napp/docker-aws-cli'
variables:
AWS_BUCKET: ******-docker
PM_S3_FOLDER: ********_manager
SNAP_S3_FOLDER: ********_GDAL3_SNAP
********_manager:
inherit:
default: [image]
variables: [PM_S3_FOLDER]
script:
- zip -jrm Dockerfile.zip docker_containers/********_manager/redis/Dockerfile docker_containers/********_manager/redis/buildspec.yaml
- aws s3 cp Dockerfile.zip s3://******-docker/$PM_S3_FOLDER/
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event" && $CI_COMMIT_BRANCH == "master"'
changes: # Include the job and set to when:manual if any of the follow paths match a modified file.
- ********/docker_containers/********_manager/redis/Dockerfile
- ********/docker_containers/********_manager/redis/buildspec.yaml
allow_failure: true
when: never
- when: on_success
snap:
inherit:
default: [image]
variables: [SNAP_S3_FOLDER]
script:
- zip -jrm Dockerfile.zip docker_containers/********_GDAL3_SNAP/Dockerfile docker_containers/********_GDAL3_SNAP/buildspec.yaml
- aws s3 cp Dockerfile.zip s3://signaleyes-docker/$SNAP_S3_FOLDER/
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event" && $CI_COMMIT_BRANCH == "master"'
changes: # Include the job and set to when:manual if any of the follow paths match a modified file.
- ********/docker_containers/********_GDAL3_SNAP/Dockerfile
- ********/docker_containers/********_GDAL3_SNAP/buildspec.yaml
allow_failure: true
The issue seems to be with the rules of the inherit job
- if: '$CI_PIPELINE_SOURCE == "merge_request_event" && $CI_COMMIT_BRANCH == "master"'
changes: # Include the job and set to when:manual if any of the follow paths match a modified file.
- ********/docker_containers/********_manager/redis/Dockerfile
- ********/docker_containers/********_manager/redis/buildspec.yaml
allow_failure: true
when: never
- when: on_success
Quoting from https://docs.gitlab.com/ee/ci/jobs/job_control.html#rules-examples
If you use a when clause as the final rule (not including when: never), two simultaneous pipelines may start. Both push pipelines and merge request pipelines can be triggered by the same event (a push to the source branch for an open merge request).
In order to avoid this rewrite the rules to run the job only in very specific cases, and avoid a final when rule. In your case remove
- when: on_success
Or use workflow to specify which types of pipelines can run
I have a job in a pipeline as such:
msi_build:
stage: Build
script:
- cd project_name
- ls -a
- wine python setup.py bdist_msi
rules:
- if: '$CI_COMMIT_REF_NAME == $BUILD_BRANCH'
- changes:
- /*.{py, html, css, yml, json}
tags:
- pywine
artifacts:
when: on_success
paths:
- /builds/$CI_PROJECT_PATH/project_name/dist/*.msi
expire_in: 1 yrs
But this also runs when I tag a commit and push it in another branch.
BUILD_BRANCH is master. This won't run when only pushing normal commits to other branches. And it'll run when pushing to master. But for some reason unknown to me, it also runs on tagged commits. What is the cause?
If it matters I used: git push --atomic origin <branch name> <tag> when pushing to another branch.
rules:
- if: '$CI_COMMIT_REF_NAME == $BUILD_BRANCH'
- changes:
- /*.{py, html, css, yml, json}
is not
rules:
- if: '$CI_COMMIT_REF_NAME == $BUILD_BRANCH'
changes:
- /*.{py, html, css, yml, json}
The first one runs when $CI_COMMIT_REF_NAME == $BUILD_BRANCH OR when the files were changed. The second one runs the job when that and that is equal AND the files with extensions were changed. Most probably in the commit the tag is run for the files with those extensions were changed, so the command is run, ignoring the first condition, because it's "or".
It's a good idea to add when: on_success to rules: explicitly, so it's nicely visible.
I have many rules in my CI config, and also many anchors.
It's not an offence to the linter to mention rules: multiple times per job, but the same linter does not help with testing whether multiple rules: clauses add up and in which order.
So the trouble is, now I have to repeat the slightly changing set of rules in every job.
.build-rules: &build-rules
rules:
- if: '$DEPLOY_TAG'
when: never
- if: '$CI_COMMIT_REF_NAME == "master"'
- if: '$CI_PIPELINE_SOURCE == "web"'
- if: '$CI_COMMIT_REF_NAME =~ "/^v[0-9]+\.[0-9]+.*$/"'
job_with_changed_rule:
<<: *build-rules
rules:
- if: '$DEPLOY_TAG'
script:
- do something
job_with_another_rule:
<<: *build-rules
rules:
- if: '$CI_PIPELINE_SOURCE == "schedule"'
script:
- do something else
Before Gitlab 14.3 the only thing you could do was placing extends block
But now you can re-use rules from other jobs with !reference tag.
For more details see this docs
The following gitlab ci job will run if the variable $CI_COMMIT_TAG is set OR if the ./versions.txt file has changed.
some-job:
script:
- echo "Do some fancy stuff.";
rules:
- if: $CI_COMMIT_TAG
when: always
- changes:
- ./versions.txt
However, what I need is for this job to run when $CI_COMMIT_TAG is set AND ./versions.txt is changed. I don't want the job to run if only one of these evaluates to true. This was the behaviour in only/changes feature, but the only (and except)-feature is less powerful and deprecated.
Is what I want currently possible with gitlab ci?
From Docs:
In the following example:
We run the job manually if Dockerfile or any file in docker/scripts/ has changed AND $VAR == "string value". Otherwise, the job will not be included in the pipeline.
docker build:
script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
rules:
- if: '$VAR == "string value"'
changes: # Will include the job and set to when:manual if any of the follow paths match a modified file.
- Dockerfile
- docker/scripts/*
when: manual
Your code will look something like this.
some-job:
script:
- echo "Do some fancy stuff.";
rules:
- if: $CI_COMMIT_TAG
changes:
- versions.txt
when: manual
I have a pages job that I want to run manual on branches, but automatically triggered on master:
pages:
stage: deploy
cache:
paths:
- public
script:
- scripts/pages.sh
artifacts:
paths:
- public
expire_in: 2 days
So I want a combination of:
only:
- master
when: always
only:
- branches
except:
- master
when: manual
Is that possible?
This should be possible to do if you use GitLab CI rules. This is an example where the shell is powershell and it shows the current time and branch/tag name:
pages:
script:
- mkdir public
- date > public\index.html
- $CI_COMMIT_REF_NAME >> public\index.html
artifacts:
paths:
- public
rules:
- if: '$CI_COMMIT_BRANCH == "master"'
when: always
- if: '$CI_COMMIT_BRANCH == null'
when: never
- when: manual
GitLab matches each individual rule from top to bottom. If the branch is named 'master', the job gets marked with when: always. If the branch name is null, this is a tag, and the job is marked with never. If this is not a branch named master, nor a tag, this is a normal branch, and the job is marked with manual.
As Aleksey Tsalolikhin described, you can remove this rule:
- if: '$CI_COMMIT_BRANCH == null'
when: never
You will then get the option to run the pipeline for your tags as well, like this:
If this is what you want or not, that is up to you.
I've tweaked the answer by MrBerta -- the third command was missing the echo command.
I also changed the slashes from backslashes to regular forward slashes so I can use the Linux shell rather than Powershell.
It now works.
Here is the gitlab-ci.yml file -- with credit to MrBerta.
pages:
script:
- mkdir public
- date > public/index.html
- echo $CI_COMMIT_REF_NAME >> public/index.html
artifacts:
paths:
- public
rules:
- if: '$CI_COMMIT_BRANCH == "master"'
when: always
- if: '$CI_COMMIT_BRANCH == null'
when: never
- when: manual
I tried pushing to master, and my GitLab Pages content was updated as expected; and I tried pushing to a feature branch, and the manual "Play" button came up in the CI/CD pipeline UI.
When I pushed a tag (with detached head, i.e., not on any branch), I could not test it -- GitLab CI did not run a pipeline automatically, and when I tried to Run Pipeline, and picked my tag, GitLab threw an error: "The form contains the following error: No stages / jobs for this pipeline."
So, I would simplify this to:
pages:
script:
- mkdir public
- date > public/index.html
- echo $CI_COMMIT_REF_NAME >> public/index.html
artifacts:
paths:
- public
rules:
- if: '$CI_COMMIT_BRANCH == "master"'
when: always
- when: manual
This pages job runs manually on branches (and tags but I couldn't test it), but automatically triggered on master, as the original poster requested.
You will need to define two stages. you can either copy/paste or use anchors:
.deploy_stage: &deploy_stage
stage: deploy
cache:
paths:
- public
script:
- scripts/pages.sh
artifacts:
paths:
- public
expire_in: 2 days
deploy_manual:
<<: *deploy_stage
only:
- branches
when: manual
deploy_master:
<<: *deploy_stage
only:
- master