In the project I am currently working on, I want to run the bitbucket pipeline according to the following rules.
Test and lint steps should run for each commit pushed to Branch.
The test-with-coverage and lint steps must be run for each record
opened with Pull Request.
The problem here is that if I push a commit to a branch that I have opened a pull request, the pipeline is triggered twice.
pipelines:
default:
- step: *lint
- step: *test
pull-requests:
'**':
- step: *lint
- step: *test-with-coverage
I looked for a way to skip default pipeline if a pull request exists, but I can't find it. I am open to suggestions and opinions.
pipelines:
default:
- step: *lint
- step: *test
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
when: never
pull-requests:
'**':
- step: *lint
- step: *test-with-coverage
Related
This is my gitlab-ci.yml:
workflow:
rules:
- if: $CI_COMMIT_MESSAGE =~ /-draft$/
when: never
- if: $CI_PIPELINE_SOURCE == "push"
include:
- '/gitlab-ci/includes.yml'
- '/idt-test-stub/gitlab-ci.yml'
variables:
ALPINE_VERSION: "3.16"
NODE_VERSION: "14-alpine"
ESLINT_CONFIG_PATH: "./.eslintrc.js"
SOURCE_DIR: "."
BUILD_TYPE: MAVEN
MVN_CLI_OPTS: "--batch-mode"
MVN_OPTS: "-Dmaven.repo.local=.m2-local -f wiremock-java/pom.xml"
MAVEN_IMAGE: "maven:3-jdk-11"
stages:
- test
- code-quality
- code-test
- code-analysis
- verify
- transform
- application-build
- image-build
- move-container-tests
- container-image-test
- image-push
.branches: &branches
only:
- branches
todo-check:
<<: *branches
shell-check:
<<: *branches
docker-lint:
<<: *branches
unit-test:
<<: *branches
artifacts:
expire_in: 20 mins
paths:
- ./coverage
verify:
<<: *branches
stage: verify
image: node:$NODE_VERSION
script:
- npm install
- ./run-verify.sh
tags:
- docker-in-docker-privilegedx
My understand is that if I commit a change including the word 'draft' in my commit message, when I push it, my workflow rules should stop the pipeline from running and yet it doesn't.
All the jobs in the pipeline get run.
The workflow rules part is copied directly from the Gitlab documentation which says this:
In the following example:
Pipelines run for all push events (changes to branches and new tags).
Pipelines for push events with -draft in the commit message don’t run, because they are set to when: never.
Pipelines for schedules or merge requests don’t run either, because no rules evaluate to true for them.
It's because of the $ at the end of /-draft$/. $ is a special character in regular expressions and matches the end of a piece of text.
Even trying to use $ for its purpose in Gitlab and using a commit message like 'Commit -draft' still fails though. I don't know why. Perhaps they don't support the $ character at all.
If you just want to check whether your commit message contains the word draft or not, you can omit the - and the $ at the end:
workflow:
rules:
- if: $CI_COMMIT_MESSAGE =~ /draft/
when: never
I tested it on Gitlab:
PS. I've created a merge request on Gitlab to fix this part of their docs, so let's see what they say.
I am trying to setup CI in gitlab so
the second job (pushdev) will be available for running manually only after the devjob has run successfully.
the third job pushtostage will only run iff file has changed.
the way the jobs are setup, second and third jobs alway run. What is missing in the pipeline spec
devjob:
image: node:16
stage: publishdev
script:
- echo "running validation checks"
- npm run validate
rules:
- changes:
- ./src/myfile.txt
- when: manual
# - this jobs needs to run after "devjob" has run successfully
# and myfile.txt has changed
# - "needs" artifacts from the "lint" job
pushdev:
image: node:16
stage: publishdev
needs: [ "devjob", "lint"]
script:
- echo "Pushing changes after validation to dev"
- npm run pushdev
rules:
- changes:
- ./src/myfile.txt
when: on_success
- when: manual
pushtostage:
image: node:16
stage: pushstage
script:
- echo "Pushing changes to stage"
rules:
- changes:
- ./src/myfile.txt
- when: manual
I change your sample to look like this:
stages:
- publishdev
- pushstage
default:
image: ubuntu:20.04
lint:
stage: publishdev
script:
- echo "lint job"
devjob:
stage: publishdev
script:
- echo "running validation checks"
rules:
- changes:
- README.md
when: manual
allow_failure: false
pushdev:
stage: publishdev
needs: [ "devjob", "lint"]
script:
- echo "Pushing changes after validation to dev"
rules:
- changes:
- README.md
when: manual
allow_failure: false
pushtostage:
stage: pushstage
script:
- echo "Pushing changes to stage"
rules:
- changes:
- README.md
when: manual
allow_failure: false
I add allow_failure: false, because allow_failure when manual job default is true.
I merge your rules. because GitLab rules one - is one rule:
Rules are evaluated when the pipeline is created, and evaluated in order until the first match.
your .gitlab-ci.yml first job devjob is manual, so it is always a success, and your second job pushdev first rule changes and when: on_success always match, so it always run.
I change your .gitlab-ci.yml, first job devjob merge your rules when file change and set it is manual job and not allow_failure. and so on.
the sample code in Files · try-rules-stackoverflow-72594854-manual · GitLab PlayGround / Workshop / Tryci · GitLab
I am unable to find a solution for how to ignore changes made in .gitlab-ci.yml to trigger a job. So far I have tried the below options:
except:
changes:
- .gitlab-ci.yml
and
only
- Branch A
but every time i make changes in .gitlab.ci-yml file, jobs for Stage B get added in pipeline and show as skipped.
Below are the jobs defined in .gitlab-ci.yml. Do you have any suggestion here?
I do not want Stage B jobs get added in pipeline when:
i) push made against the .gitlab-ci.yml (either manual changing file or git push command)
ii) any merge request for .gitlab-ci.yml
stages:
- A
- B
Stage A:
stage: A
script:
- echo "TEST"
rules:
- if: '$CI_COMMIT_TAG =~ /^\d+\.\d+\.DEV\d+/'
tags:
- runner
Stage B:
stage: B
script:
- echo "TEST"
when: manual
tags:
- runner
With this setup the Stage B is not added if .gitlab-ci.yml is modified:
stages:
- A
- B
Stage A:
stage: A
script:
- echo "Stage A"
tags:
- runner
Stage B:
stage: B
script:
- echo "Stage B"
rules:
- changes:
- ".gitlab-ci.yml"
when: never
- when: manual
tags:
- runner
Otherwise Stage B is showed in the pipeline and can be run manually. Tested with GitLab CI CE 14.1.0.
Could you try using workflow rule? It should determine if the pipeline is created.
P.S: Someone complained a couple of years ago about not being able to activate manual jobs after the exception, but it looks like it was a bug. I can't find the issue mentioned in the post
Edit:
This conf skips any commit with changes README.md or .gitlab-ci.yml:
workflow:
rules:
- if:
changes:
- README.md
- .gitlab-ci.yml
when: never
I have a gitlab-ci.yml file like this, and want to run it only on Branch Master. If there is a push into develop branch the Pipeline should NOT start.
I tried with 'only' keyword, but it shows an Error.
stages:
- info
- build
- test
- review
- cleanup
- deploy-dev
- integration-test
- deploy-test
- system-test
- deploy-production
only:
refs:
- master
To define a trigger rule for every stage you can use the workflow keyword, like this:
workflow:
rules:
- if: $CI_COMMIT_TAG
when: never
- if: $CI_COMMIT_BRANCH == 'master'
This has to be on the "root" of your yaml, as it is not part of any job in particular.
In the example above, I am telling the pipeline to avoid running when a repository tag is pushed and to run only when a commit is done in the master branch.
You can use this as a base and add other conditions to trigger the stages in the pipeline, the complete documentation on this matters can be found here: https://docs.gitlab.com/ee/ci/yaml/#workflow
I thin you have an indentation problem here.
It should be something like:
stages:
- job_1
- job_2
- ....
- job_n
job_1:
stage: job_1
....
only:
refs:
- master
job_2:
stage: job_2
....
only:
refs:
- master
....
You need to define the target branch for each stage.
I have a development and a master branch. I pushed the bitbucket-pipeline.yml to the master branch and realized, that want to run my pipeline on the develop branch. Is it best practice to to commit it first on the development branch?
If you have bitbucket-pipelines.yml in a branch - then the file will be used for pipelines when you commit something to this branch, if you create a PR then the file from the first branch will be used (the same as commit).
The best practice is to have the file in every branch with a config that shares logic for all branches / tags / pull requests and if you need different rules for different branches - simply specify them in the bitbucket-pipelines.yml.
this file I have in every branch:
image: satantime/puppeteer-node:12.16.1-buster
pipelines:
default:
- step: &Preparation
- step: &Manual
- step: &BuildAOT
- step: &Lint
- step: &CodeStyle
- step: &LintTs
- step: &LintCss
- step: &UT
- step: &E2E
- step: &BuildDocker
pull-requests:
'**':
- step: *Preparation
- step: *Manual
- parallel:
- step: *CodeStyle
- step: *Lint
- step: *BuildAOT
- parallel:
- step: *UT
- step: *E2E
- step: *BuildDocker
branches:
'**': # <- rules for all branches
- step: *Preparation
- step: *BuildDocker
'master': # <- rules for the master branch
- step: *Preparation
- step: *UT
- step: *E2E
- step: *BuildDocker