I have created a simple readme file in the main repository. Now for example if someone creates a feature branch out of the main branch and edits the readme file. Those commits will be then committed in the feature branch.
Now I want to create a pipeline which should do the following:-
Whenever there is a push in the repo it should run the pipeline automatically.
The pipeline should check that every NEW content to the README.md has to have at least a one time mentioning of words like "ABQ" OR "abq" OR "albuquerque" OR "Albuquerque".
So basically The push based pipeline shall check if the added text in the feature branch does at least have one occurrence of the above mentioned words.
Here is the yml file i have that runs whenever there is a push. Can someone guide me here for achieving the above goal?
workflow:
rules:
- if: $CI_PIPELINE_SOURCE == "push"
when: always
Related
I have GITLAB setup to pull repository from bitbucket.
I want pipeline to run automatically when there is pull request and when there are changes in files.
But it seems to not work.
This is the rule I have setup in pipeline:
rules:
- if: $CI_PIPELINE_SOURCE == "external_pull_request_event"
changes:
- Dockerfile
when: manual
Kindly help to debug
I want pipeline to run automatically
Then the first thing to change would be to remove the when:manual, which is used to require that a job doesn’t run unless a user starts it.
The combination you used (rules/if/changes/when:manual) was seen in the GitLab documentation at "Complex rules", but does not fit what you expressed in your question.
We're running a self-hosted GitLab CE instance. I'm trying to construct a very particular ruleset that works in our project environment. I'm aware of the basic building blocks: branch pipelines and MR pipelines, workflow:rules for pipelines, rules for jobs, predefined $CI_* variables, etc. I'm having trouble bringing them all together in a way that would also avoid duplicate pipelines, a common problem that may require very specific rule definitions to overcome.
We have a main branch from which feature branches are created, and merged back via merge requests. Occasionally some trivial fixes are pushed directly to main.
We've defined a pipeline with three jobs, currently all set to when: manual until we figure out this scheme. The eventual goal is this:
pre-build tests (stage: .pre)
Always runs as the first job, when the pipeline runs.
Has allow_failure: false – if the tests don't pass, no further jobs should run.
build (stage: build)
Conditions detailed below.
deploy to production (stage: deploy)
Should only be run manually in all situations.
Has dependencies: [build]
The conditions we'd like to have for the creation of the entire pipeline:
A merge request for a feature branch is merged to main: run the pipeline for main.
Commits are pushed directly to main: run the pipeline for main.
(Side note: we want to prevent duplicate pipelines from the above two conditions.)
Commits are pushed to a new or existing feature branch: run the pipeline for the feature branch. Does not matter if it has an open MR or not.
All other cases (tags, new MR creation from/to any branch, etc.): DON'T run the pipeline.
If the pipeline runs, a couple of extra conditions for the build job specifically:
The pipeline is running for the main branch (via a push or an MR, doesn't matter): always build, assuming the tests passed.
The pipeline is running for a feature branch: must build manually.
Achieving this setup is probably not THAT many rules in total, but I'd like to not have to do hours of trial and error if this is something that an expert can readily help with.
I eventually figured it out. Here's how the above conditions are met, just in case they're of use to someone else down the line:
workflow:
rules:
# Explicitly enable merge request pipelines to be created (not done by default)
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
# Prevent duplicate pipelines from push events to branches that are the source
# branch of one or more open merge requests. If $CI_OPEN_MERGE_REQUESTS is
# non-empty on a branch pipeline, it means that the the above rule has already
# caused (or will cause) a merge request pipeline to run. These rules are
# separately evaluated for the merge request event resulting from the same push.
- if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS
when: never
# Run a normal branch pipeline on a branch that isn't the source of an open MR
- if: $CI_COMMIT_BRANCH
pre-build tests:
stage: .pre
when: always
allow_failure: false
# etc.
build:
stage: build
rules:
# Automatically done assuming tests pass, but only on the default branch.
# Also runs when a feature branch MR is merged to the default branch; the
# pipeline source for that is again `push`, not `merge_request_event`.
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
when: on_success
- when: manual
# etc.
deploy to production:
stage: deploy
when: manual
dependencies: [build]
# etc.
The one part of the question that I couldn't do is this one:
new MR creation from/to any branch: DON'T run the pipeline
...while also satisfying this one (much more important):
Commits are pushed to a new or existing feature branch: run the pipeline for the feature branch.
A merge request pipeline is run when a merge request is created for an existing branch. When that branch was first pushed, a branch pipeline was run for a certain $CI_COMMIT_SHA. When the MR creation event pipeline runs, it builds for that same SHA. (However, this doesn't constitute a "duplicate pipeline" as described, because the pipelines are created by two different user actions—unlike a single push to an MR source branch without the $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS trick.)
There's no official way of preventing this; a related GitLab issue can be found here, open as of this writing. Thankfully, the practical impact of this is negligible in our case.
I am lots of branches in my repo, now I want to add MR pipeline for the master branch, and enable the Merge checks and Pipelines must succeed optional. unfortunately the repo have so many branches that I don't want to create .gitlab-ci.yml for them one by one. but as I have enabled the options for merge check, MR to the branched are stuck because they are not passed pipeline(no pipeline is configured for the branch).
So anyone can help me out?
Can you also paste an snipped of your .gitlab-ci.yml file?
Hoping you must have tried this to your stages?
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event" && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == 'master'
This basically will run only for a merge request to the master branch. And this chunk should be inside the source branch .gitlab-ci.yml
I have created a pipeline in my repository which is used to validate code by executing unit tests for code that is being pushed to features/* branches. The same pipeline is used as Build validation pipeline set as Branch Policy on the develop branch to validate incoming PRs. This is the trigger of the pipeline.
# pipeline.yml
trigger:
batch: false
branches:
include:
- features/*
However we have come across the following condition: Given an open PR from refs/heads/features/azure-pipelines -> refs/heads/develop we push a commit on the features/azure-pipelines branch.
This causes the pipeline to trigger twice. To my understanding one of the runs is due to the trigger of the pipeline (The one marked as Individual CI on the screenshot) and the second run is due to branch policy trying to validate code being pushed onto the open PR to develop. (The PR Automated)
Is there any way to disable one of the executions since it's essentially a duplicate? I was maybe looking for a way to retrieve open PRs and abort execution of a pipeline for Individual CI if there is an open PR for a branch but I am not sure that's the best way around that and I am looking for options.
You can set
trigger: none
This way only the branch policy will trigger the pipeline.
Is there any way to disable one of the executions since it's essentially a duplicate?
As we know, we could not disable the Build validation pipeline set as Branch Policy on the develop branch to validate incoming PRs unless we cancel the Build validation.
For your situation, you could try to include [skip ci] in the commit message or description of the HEAD commit to make the Azure Pipelines skip running CI when you plan to merge the features branch to the develop branch.
You could check the document Skipping CI for individual commits for some more details.
Here it depends if they does the same. You can have conditional checks in the pipeline which does a different things for PR and CI runs. However, I'm pretty sure that this is not possible, because one is defined on the YAML and the second on the Azure DevOps portal. So even if you disnle PR trigger here in YAML, a branch policy still runs a PR. And you can specify antyhing in YAML to block branch policy.
I have a Question about the Pipline trigger in Devops.
My team and I are using Azure Devops to develop a software.
We use a Branch Specific trigger, to start the pipeline only in out Master Branch. The other branches are ignored in the YAML File.
First part of my question is, that we don't know a way how to trigger the Pipeline over a commit message in our Git tool.
For example: "We work in a different branch than the Master branch -->No Pipeline is running. But we want to trigger the pipeline in this Branch for a Specific test just one time. Our way would be to insert a specific command in the commit text to trigger the pipeline."
My second question is, if it's possible to run different stages in different Branches in one YAML file.
Here again an example: " In our different Branch, we just want to run our unit tests every push. In our Master Branch we want to run our unit tests and after that, we want to build our application.
So far, we started the pipeline at every push and build a new image everytime. But we dont want that, because some pushs arent working and we just push it. We want to decide when the pipeline is running and whitch stage is running.
I hope you can understand my problem. For further questions, please comment here.
Thanks
Question 1:
You can consider using tag triggers to do this. Here is an example:
trigger:
branches:
include:
- master
tags:
include:
- test.*
Then the pipeline will be triggered when working on the master branch or the commit tag is test.*.
Question 2:
You can use conditions. Here is an example:
condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/master'))
Add the condition to your stage, and then the stage will be only triggered by the master branch.
Question 3:
So far, we started the pipeline at every push and build a new image everytime. But we dont want that, because some pushes aren't working and we just push it.
You can skip CI for individual commits.
Just include [skip ci] in the commit message or description of the
HEAD commit and Azure Pipelines will skip running CI.
Update 1:
For Question 1, the test.* means a tag which started with test., such as test.1, test.0.1, and so on. You can change the test.* to anything you want.
As for the question your encountered, you can't create a tag called test.* directly because a tag name cannot contain *.
To avoid confusion, you need to create a tag for the commit to trigger the tag CI, rather than writing it directly in the commit text.
The idea
insert a specific command in the commit text to trigger the pipeline.
I don't think is currently supported and tag trigger is an alternative.
Click this document for detailed information about git tag.
Update 2:
Trigger the stage by master branch or 1620-to-PipelineTrigger branch:
condition: or(eq(variables['Build.SourceBranch'], 'refs/heads/main'), eq(variables['Build.SourceBranch'], 'refs/heads/1620-to-PipelineTrigger'))
You can set only one condition per stage, but you can create more complex conditions using and, or and ().
Click this document to get more detailed information and examples about conditions.