3

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?

Improve this question

2 Answers 2

Reset to default
6

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]/
Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

That's perfect, thank you! We use templated portions already so I should have thought of that!
2

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.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.