I am not quite sure how the gitlab CI workflow should look like to achieve this:
What I want to do with gitlab CI:
grunt bump
should be executed Summary
So grunt bump
should only executed if on master and after successful tests and merging. Only for the resulting commit (Release vx.x.x) the build and deploy job should be done...
Maybe there is a smarter workflow then this idea. Basicly I want to bump version value and tag the commit after merging and successful tests...
My attempt for YAML-file
stages:
- test
- build
- deploy
lint:
image: testing:latest
stage: test
tags:
- testing
script:
- /node_modules/.bin/eslint --ext .js --ext .jsx .
bump:
stage: build
tags:
- deploy
script:
- grunt bump
only:
- master
- /^Merge .*$/
build:
stage: build
tags:
- deploy
script:
- docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
- docker build -t $CI_REGISTRY_IMAGE:latest .
- docker push $CI_REGISTRY_IMAGE:latest
only:
- master
- tags
- /^Release .*$/
production:
stage: deploy
script:
- docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
- docker pull $CI_REGISTRY_IMAGE:latest
- cd /home/ubuntu
- docker-compose up -d
only:
- master
- tags
- /^Release .*$/
Go to either the git log or the GitHub UI and grab the unique commit hashes for each of the commits that you want. "Cherry pick" the commits you want into this branch. Run this command: git cherry-pick super-long-hash-here . That will pull just this commit into your current branch.
You can, however, create a new branch from your master branch, cherry-pick the single commit, and create a merge request for that branch, containing only the one commit. If you do not need the other commits any more, you can also consider an interactive rebase, to remove the unwanted commits from the branch.
The merge commit is considered a single commit (I'd expect 13 commits now, unless you're not counting merge commits or one of the 5 and 7 is actually the same commit), but it brings all of the histories it merges together.
It is possible to execute jobs only/except
based on the predefined gitlab variable $CI_COMMIT_MESSAGE
.
See gitlab ci reference.
Check also the docu on how variable expressions are handled.
commit_message_has_release_job:
only:
variables:
- $CI_COMMIT_MESSAGE =~ /^Release .*$/
[...]
It is also possible to filter for merge_requests.
merge_request_job:
only:
- merge_requests
[...]
Combining multiple cases of only/except
may not work as you might expect it. The list does not work connected with AND
, but OR
. Also, it is not 100% sure that a leading only
followed by an except
works as you expect it. So a simple workaround would be something like this:
merge_reqeuest_to_master_job:
only:
- merge_requests
before_script:
- if [[ $CI_MERGE_REQUEST_TARGET_BRANCH_NAME != "master" ]]; exit 0 ; fi
Since the variable $CI_MERGE_REQUEST_TARGET_BRANCH_NAME
is just set, if the pipeline is for a merge request, you could just do:
merge_reqeuest_to_master_job:
only:
variables:
- $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "master"
However, the feature "CI variable expression conjunction/disjunction" is implemented since 12.0.
merge_reqeuest_to_master_job:
only:
- merge_requests
To your other remarks:
allow_failure: true
or when: on_failure
)If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With