When you work on your .gitlab-ci.yml for a big project, for example having a time consuming testing stage causes a lot of delay. Is there an easy way to disable that stage, as just removing it from the stages definition, will make the YAML invalid from Gitlab's point of view (since there's a defined but unused stage), and in my case results in:
test job: chosen stage does not exist; available stages are .pre, build, deploy, .post
Since YAML does not support block comments, you'd need to comment out every line of the offending stage.
Are there quicker ways?
You could disable all the jobs from your stage using this trick of starting the job name with a dot ('.'). See https://docs.gitlab.com/ee/ci/jobs/index.html#hide-jobs for more details.
.hidden_job:
script:
- run test
There is a way to disable individual jobs (but not stages) like this:
test:
stage: test
when: manual
The jobs are skipped by default, but still can be triggered in the UI:
Also possible with rules and when as below:
test:
stage: test
rules:
- when: never
So far, the easiest way I've found is to use a rules definition like so:
test:
stage: test
rules:
- if: '"1" != "1"'
(...)
This still feels a bit odd, so if you have a better solution, I'll gladly accept another answer.
Related
I saw this code on one of the pipelines of my company.
rules:
- if: 'SOME-CONDITION'
when: manual
- when: never
variables:
...
According to gitlab ci documentation, the when:never field should be used with a condition, to basically tell the pipeline to not add the job if that condition is satisfied. I don't understand its use by itself in the end of the rules. What does it add and how the pipeline will behave without it ?
The last when: never is not needed.
Even without that line, the job will run only if SOME-CONDITION is satisfied.
For example, I want a deploy job triggered but not if the commit contains changes relating to a Makefile and/or docker-compose.yml. How can I specify those rules/conditions? Thank to anyone who is willing to help.
this can be achieved with the rules block and the fact that the rules are evaluated sequentially and stop as soon as one rule applies.
Rules are evaluated when the pipeline is created, and evaluated in order until the first match. When a match is found, the job is either included or excluded from the pipeline, depending on the configuration.
https://docs.gitlab.com/ee/ci/yaml/#rules
this means you could do something like the following as a first rule, to ensure that it is never executed.
rules:
- changes:
- docker-compose.yml
when: never
Disclaimer: i did not test this, but based on the documentation it should work like this. see https://docs.gitlab.com/ee/ci/yaml/#rules for further details
Combine if rule to test the branch, and use changes condition to test if the file is in the changeset. Be sure to order them correctly to make sure the rule with changes is first.
my_job:
rules:
- if: '$CI_COMMIT_REF_NAME == "main"'
changes:
- makefile
- docker-compose.yml
when: never # dont run when these files are changed on this branch
- if: '$CI_COMMIT_REF_NAME == "main"'
when: on_success # otherwise run normally on this branch only
See rules:changes for more information.
I am trying to execute a job on some pipeline variables. I have used 'rules' in my .gitlab-ci.yml file but getting the error "key may not be used with 'rules': only".
How can I do this?
build-dev:
stage: build
only:
- master
- branches
rules:
- if: '$CI_COMMIT_BRANCH=="my-featured-branch"'
when : never
The error you're receiving is literally what it says: you shouldn't use only with rules together in the same job.
Basically the reason is that this could lead into problems due to mixed behavior.
From the documentation:
rules replaces only/except and they can’t be used together in the same job. If you configure one job to use both keywords, the GitLab returns a key may not be used with rules error.
I have a Pipeline that has a few stages: detect, test, build, deploy
The detect stage detects the type of application and the test and build stages have jobs that are included or excluded based on what is computed in detect. The detect stage writes it's value to a environment variable called BUILD_MODE.
I am using rules like so:
ng-build:
extends:
- '.ng/job/build'
stage: build
rules:
- if: $BUILD_MODE == "ANGULAR"
when: always
npm-build:
extends:
- '.npm/job/build'
stage: build
rules:
- if: $BUILD_MODE == "NPM"
when: always
The problem with this is that the BUILD_MODE variable is evaluated statically when the pipeline is created not after the detect stage runs so the above never works unless I set the variable explicitly in the top level YML file like so:
variables:
BUILD_MODE: "ANGULAR"
What is the best way to solve this problem? The summary of what I want to do is evaluate some condition, either set the stages dynamically or set the variable itself before the stages in the Pipleline are created so they will be created with the rules evaluated correctly.
You could take a look at dynamic child-pipelines. Maybe you could solve your problem by dynamically creating your npm/ng build jobs.
We have a job (deploy to production) that we generally manually click after checking that build on staging. However, very occasionally we have an issue that we've accidentally deployed and want to get a fix out ASAP. In those case we run the tests locally (much faster) and put [urgent-fix] in our commit message to stop the tests running in CI (skipping straight to Docker image build and staging deploy).
What we'd like to do is if we put [urgent-fix] it automatically triggers the production deploy (usually a when: manual step). Can we achieve this somehow?
Sounds like you can use a combination of the only:variables syntax and $CI_COMMIT_MESSAGE predefined variable.
A rough idea (untested):
.deploy_production: &deploy_production
stage: deploy production
script:
- echo "I'm deploy production here"
tags:
- some special tag
deploy::manual:
<< *deploy_production
when: manual
allow_failure: false
deploy:urgent_fix:
<< *deploy_production
only:
variables:
- $CI_COMMIT_MESSAGE =~/[urgent-fix]/
As of GitLab v12.3 (~September 2019) GitLab comes with "Flexible Rules for CI Build config". The feature is intended to replace the only/except functionality and is fully documented here.
With rules: you can now fully influence the when: behaviour of your job based on various conditions (in contrast to only/except: which forced you to create separate jobs for situations like the one described in the OP; see accepted answer).
For example you can do:
deploy:
rules:
- if: '$CI_COMMIT_TITLE =~ /urgent-fix/'
when: on_success
- when: manual # default fallback
script:
- sh deploy.sh
One thing to highlight is that in the above example I used $CI_COMMIT_TITLE instead of $CI_COMMIT_MESSAGE (see gitlab docs) to avoid the string "urgent-fix" reoccuring in a commit message automatically assembled in the course of a git merge, which would then accidentally retrigger the job.
Disclaimer: Please be aware that the new rules: feature stands in conflict with only/except: and thus requires you to remove only/except: occurences. Also, please note that rules: should only be used in combination with workflow: (read the docs) to avoid unwanted "detached" pipelines being triggered.