I am running a Jira Cloud instance that is integrated with a Gitlab Cloud (SaaS, no paid subscription) repo using the official tools. I have successfully created several automation rules in Jira, so both apps are well configured and connected, but there is one rule that is not working, it is not being triggered
My goal is to detect in Jira when the pipeline fails in order to change the ticket status
My desired flow is
User creates Merge Request
1.1 Jira detects this event and changes ticket status
1.2 Pipeline is run for $CI_PIPELINE_SOURCE == 'merge_request_event' jobs
1.3 Pipeline finishes (uses feature branch)
1.4 Jira detects failed status and changes ticket status
User merges the MR
2.1 Jira detects this event and changes ticket status
2-2 Pipeline is run for $CI_COMMIT_BRANCH == 'main' && $CI_PIPELINE_SOURCE == 'push' jobs
2.3 Pipeline finishes (uses main branch after the merge)
2.4 Jira detects failed status and changes ticket status
This flow is working except for the last step. I have created the Jira rule for it but the rule is not being triggered. Since the rule trigger is cloned from the 1.4 rule, I am assuming that the problem is that the integration is failing, Gitlab is not publishing the event
This is my .gitlab-ci.yml file
stages: # List of stages for jobs, and their order of execution
- build
- deploy
build-job: # This job runs the build stage, which runs on Merge Request creation.
stage: build
rules:
- if: $CI_PIPELINE_SOURCE == 'merge_request_event'
script:
- echo "Compiling the code..."
- echo "Compile complete."
deploy-job: # This job runs the deploy stage, which runs on Merge into Main branch.
stage: deploy
rules:
- if: $CI_COMMIT_BRANCH == 'main' && $CI_PIPELINE_SOURCE == 'push'
script:
- echo "Deploying the code..."
- echo "Deploy complete."
- fakecommand
That fakecommand is on purpose for forcing the pipeline to fail
I created a rule for logging all build state changes.
You can see in the screenshot that all status changed are being detected but the last one (successful to failed)
Should I modified my pipeline? Should I use another rule trigger in Jira? As you can guess, my goal is to have feedback on the main branch performance after the merge is completed.
Related
I have manually generated the report of my API changes using swagger-diff
I can automate it in a local machine using makefile or script but what about if I wanted to implement it in the Gitlab pipeline, how can I generate the report in such a way when someone pushes the changes on the API endpoints
java -jar bin/swagger-diff.jar -old https://url/v1/swagger.json -new https://url2/v2/swagger.json -v 2.0 -output-mode html > changes.html
Note that: All the project code is also being containerized.
Configure a job in the pipeline to run when there are changes to your api routes. Save the output as an artifact. If you also need the diff published, you could either do the publishing in that job or create a dependent job which uses the artifact to publish the diff to a Gitlab page or external provider.
If you have automated the process locally, then most of the work is done already if it is in a shell script or something similar.
Example:
This example assumes that your api routes are defined in customer/api/routes/ and internal/api/routes and that you want to generate the diff when a commit or MR is pushed to the dev branch.
ApiDiff:
stage: build
image: java:<some-tag>
script:
- java -jar bin/swagger-diff.jar -old https://url/v1/swagger.json -new https://url2/v2/swagger.json -v 2.0 -output-mode html > changes.html
artifacts:
expire_in: 1 day
name: api-diff
when: on_success
paths: changes.html
rules:
- if: "$CI_COMMIT_REF_NAME == 'dev'"
changes:
- customer/api/routes/*
- internal/api/routes/*
- when: never
And then the job to publish the diff if you want one. This could also be done in the same job that generates the diff.
PublishDiff:
stage: deploy
needs:
- job: "ApiDiff"
optional: false
artifacts: true
image: someimage:latest
script:
- <some script to publish the report>
rules:
- if: "$CI_COMMIT_REF_NAME == 'dev'"
changes:
- customer/api/routes/*
- internal/api/routes/*
- when: never
I want GitLab CI to run a job after a merge request is merged. I don't want it to be run on CREATING a new merge request and also I don't want it to be run whenever target branch is updated. (Since it's possible to commit directly to target branch and the job should not be run in that situation.)
Is that possible?
If yes, I also want to know informations about the merge request which triggered the job.
(Actually I want to update my project management system, when a merge request is merged. Thus I need to know which merge request is merged (or approved).)
Thanks in advance.
I want GitLab CI to run a job after a merge request is merged.
Unfortunately, GitLab does not offer a "merge request merged" trigger.
What you can do, is to make the pipeline run for any push in a certain branch and use branch-protection to make sure pushs can only come from merge requests. To do that:
Set your pipeline to only run e.g. for branch main:
# if you want to use "only":
my_job:
only:
- main
# or alternatively if you want to use rules you can do the same with:
my_job:
rules:
- if: '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_REF_NAME == "master"'
Enable Branch protection to disable direct pushes to main and only allow MRs:
You can run the pipeline after merge by using Gitlab ci predefined variable $CI_MERGE_REQUEST_APPROVED this will return true after merge has been done and available from gitlab v14.1.
you can add the rule like this in your job.
rules:
- if: $CI_MERGE_REQUEST_APPROVED
Please help with gitlab-ci.yml the goal is to do not run pipeline when creating a copy branch from product named with auto-* and do not run pipeline when merging back from auto-* to product branch. BUT run pipeline when just commit to auto-* or to product and run pipeline for product when merging to it from non auto-* branches . Tried bellow workflow but does not work... pipeline runs all the time(
In short I do not want to run pipeline when creating for example auto-testing branch from product and do not want to run it when merging auto-testing back to product
By the way pipeline uploads to the same folder for both product and auto-*
workflow:
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event" && $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^auto-(.*)$/'
when: never
- if: '$CI_PIPELINE_SOURCE == "merge_request_event" && $CI_COMMIT_BRANCH =~ /^auto-(.*)$/'
when: never
- if: '$CI_COMMIT_BRANCH == "product" || $CI_COMMIT_BRANCH =~ /^auto-(.*)$/'
Your problem is, that '$CI_PIPELINE_SOURCE == "merge_request_event" only covers pipelines that run within merge requests, not those that run after you merge it. GitLab does not differentiate Merge-Request results from normal pushes, so for those the variable will hold CI_PIPELINE_SOURCE=push.
In fact, there is no built-in way in GitLab to determine where a MR came frome that triggered a pipeline. As explained here you can use a workaround to get this information using the API.
Maybe a solution for you could be to built a pipeline that runs, requests the source branch using the API and immediately stops if the source branch starts with auto-*.
Given the following .gitlab-ci.yml:
---
stages:
- .pre
- test
- build
compile-build-pipeline:
stage: .pre
script: [...]
artifacts:
paths: [".artifacts/build.yaml"]
lint-source:
stage: .pre
script: [...]
run-tests:
stage: test
rules:
- if: '$CI_COMMIT_BRANCH == "$CI_DEFAULT_BRANCH"'
trigger:
strategy: depend
include:
artifact: .artifacts/tests.yaml
job: "compile-test-pipeline"
needs: ["compile-test-pipeline"]
build-things:
stage: test
rules:
- if: '$CI_COMMIT_BRANCH == "$CI_DEFAULT_BRANCH"'
trigger:
strategy: depend
include:
artifact: .artifacts/build.yaml
job: "compile-build-pipeline"
needs: ["compile-build-pipeline"]
...
The configuration should always run (any branch, any source). Tests and build jobs should be run only on the default branch.
However, no jobs are run for merge requests, and manually triggering the pipeline on branches other than the default one give the error No Jobs/Stages for this Pipeline.
I've tried explicitly setting an always run rule using rules: [{if: '$CI_PIPELINE_SOURCE'}] to the jobs in the .pre stage, but no dice.
What am I doing wrong?
As per the docs:
You must have a job in at least one stage other than .pre or .post.
In the above configuration, no jobs other than the ones in .pre are added on merge request events, hence no jobs are added at all.
I'm glad you added this info into the question: However, no jobs are run for merge requests
CI_COMMIT_BRANCH is not available in MR-based events. Here is an fragment from official docs:
The commit branch name. Available in branch pipelines, including pipelines for the default branch.
**Not available in merge request pipelines or tag pipelines.**
When working with MR and willing to check against branch name, you might want to use:
CI_MERGE_REQUEST_SOURCE_BRANCH_NAME or CI_MERGE_REQUEST_TARGET_BRANCH_NAME
List of envs here
It seems rules replaces only/except functionality in the latests GitLab versions.
Before, specifying that a job had to be executed only for master branch, for example, was very straightforward.
How would that be done with rules?
I'm guessing GitLab provides some variable that specifies the current branch's name, but I cannot find that. The only examples I see are regarding merge requests.
In other words, if I have the following job, how to restrict it to run only in potato branch?
unit_tests:
stage: test
script: dotnet vstest test/*UnitTests/bin/Release/**/*UnitTests.dll --Blame
rules:
- exists:
- test/*UnitTests/*UnitTests.csproj
I guess this would be it:
unit_tests:
stage: test
script: dotnet vstest test/*UnitTests/bin/Release/**/*UnitTests.dll --Blame
rules:
- if: $CI_COMMIT_BRANCH == "potato"
Here are the variable references:
https://docs.gitlab.com/ee/ci/variables/predefined_variables.html
Here is an example from gitlab-runner project source code itself
https://gitlab.com/gitlab-org/gitlab-runner/-/blob/main/.gitlab/ci/test.gitlab-ci.yml
job-name:
script:
- echo "i am potato"
rules:
- if: '$CI_COMMIT_BRANCH == "potato"'