In Azure DevOps, created pipeline using Yaml file and mentioned "develop" under Triggers section. It is triggering for new commits in develop branch but also triggering for new branch creation based on "develop" branch which is not happening when I create a static pipeline. How can I prevent build for new branch. Any help here?
I think you should use the include / exclude filters like below :
# this is being defined in app-ci pipeline
resources:
pipelines:
- pipeline: securitylib
source: security-lib-ci
trigger:
branches:
include:
- releases/*
exclude:
- releases/old*
Just check this page and you should find your answer : https://learn.microsoft.com/en-us/azure/devops/pipelines/process/pipeline-triggers?view=azure-devops
Regards
Could you try this ?
trigger:
batch: true
branches:
include:
- develop
Related
I need to integrate a Gitlab CICD pipeline with a custom Delivery Manager Tool. My pipeline will need to invoke the delivery manager API with some info.
In Jenkins we developed a plugin that provided a pipeline step - void deployEnv (String app, String environment ) - that can be used in the different stages, e.g.:
deployEnv("applicationx", "production")
Is there a way to develop a similar plugin in Gitlab CICD?
Is it possible to invoke a remote URL from a Gitlab CICD pipeline passing some credentials?
The closest analog for this kind of "plugin" in GitLab CI is probably a CI templated job definition. There's maybe a few ways to formulate this. There are a number of methods for abstracting and including job definitions provided by others. Some of the basic tools are: include:, extends:, !reference, "hidden job" keys, and YAML anchors.
Providing reusable templates
If you just need to provide an abstraction for a series of steps, a "hidden key" definition would be the closest to what you want.
Consider the following template YAML. This might be embedded directly in your .gitlab-ci.yml file(s) or you might choose to include it any number of configurations from a remote location using the include: keyword.
In this fictional example, we provide a script step that expects two environment variables to be present: APPLICATION_NAME and DEPLOYMENT_ENV. These variables are used (in this fictional example) to call a remote API passing those values as path parameters. Here, the definitions are provided in a "hidden job" key
.deploy_to_env:
image: curlimages/curl # or otherwise have `curl` in your environment
script:
- |
if [[ -z "$APPLICATION_NAME" || -z "$DEPLOYMENT_ENV" ]]; then
echo "FATAL: you must set APPLICATION_NAME and DEPLOYMENT_ENV variables"
exit 1
fi
- curl -XPOST "https://my-deployment-api.example.com/${APPLICAITON_NAME}/${DEPLOYMENT_ENV}"
Let's assume this yaml file exists in a file named deploy.yml in a project whose path is my-org/templates.
Using templates
Now let's say a pipeline configuration wants to leverage the above definition to deploy an application named applicationx to production.
First, in any case, the project should include: the remote definition (unless you choose to embed it directly -- e.g., copy/paste).
include:
- project: my-org/templates
file: deploy.yml
ref: main # or any git ref, or omit to use default branch
Then you can use the extends: keyword to form a concrete job from the hidden key.
deploy_production:
stage: deploy
extends: .deploy_to_env
variables:
APPLICATION_NAME: "applicationx"
DEPLOYMENT_ENV: "production"
Or, if you want to embed the deployment steps in the middle of other script steps using !reference is useful here.
deploy_production:
stage: deploy
script:
- export APPLICATION_NAME="applicationx"
- export DEPLOY_ENV="production"
# these could also be set in `variables:`
- echo "calling deployment API to deploy ${APPLICATION_NAME} to ${DEPLOY_ENV}"
- !reference [.deploy_to_env, script]
- echo "done"
There's a lot of ways to handle this, these are just two examples.
My azure-pipeline.yml is defined like this:
trigger:
branches:
include:
- master
- develop
steps:
-task1
-task2
-task3
On each push to develop branch the pipeline is triggered - as expected.
I want to trigger the same pipeline on the feature branch.
I created the new branch from develop branch. The name is featureBranch.
I edited azure-pipeline.yml to look like this:
trigger:
branches:
include:
- master
- develop
- featureBranch
steps:
-task1
-task2
-task3
When I push the code to featureBranch the pipeline will not trigger. I have tried also this but without success:
trigger:
branches:
include:
- '*'
A common error scenario is that there are UI Settings which override your YAML-Settings. You can check that in ADO-UI under Pipelines -> the "three dots" -> Triggers.
Also try to include filepaths to further test your scenario:
> trigger:
> paths:
> include: *
Agree with vollmer.io. You could edit this yaml pipeline and check its Triggers settings.
If there are UI trigger settings which override your yaml trigger settings.
In addition, if you want to trigger this pipeline when there are pushes to all branches, the following syntax should work.
trigger:
branches:
include:
- /*
See: CI triggers for more details.
I'm using Azure DevOps's multiple repository functionality, documented here:
​https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/multi-repo-checkout?view=azure-devops
I have my YAML file in one repo, and the pipeline points to that YAML. The YAML has a trigger set up for another repository resource, so that when that repo gets updated, the pipeline will be triggered:
resources:
repositories:
- repository: MyRepo
endpoint: 'MyRepos'
type: git
name: RepoName
trigger:
- '*'
The documentation claims that the 'Build.SourceBranch' variable will allow me to determine which branch in MyRepo triggered the pipeline build: "When an update to one of the repositories triggers a pipeline, then the following variables are set based on triggering repository"
However, this doesn't seem to be the case. No matter what branch triggers the build, 'Build.SourceBranch' is always 'refs/heads/master', presumably because the repo that holds the YAML has 'master' as its default branch.
I can't find any environment variable that gets set to the name of the branch that triggered the build, either. So how can I get the name of the branch that triggered the build? If there's no possible way, I think this needs to be added!
The issue is:
According to the document, Build.SourceBranch is set based on triggering repository. However, its value is determined by repo in which the YAML file resides in practice.
I have done following tests. There are two repos, 'RepoA' and 'RepoB'. Both repos have two branches, 'master' and 'bran'. And the YAML file is in 'master' of 'RepoA'
Commit a change in 'bran' of 'RepoB'. The value of Build.SourceBranch is refs/heads/master. It is not consistent with the documentation.
Commit a change in 'bran' of 'RepoA'. The value of Build.SourceBranch is refs/heads/bran. It is consistent with the documentation.
Commit a change in 'master' of 'RepoB'. The value of Build.SourceBranch is refs/heads/master. It is consistent with the documentation.
Commit a change in 'master' of 'RepoA'. The value of Build.SourceBranch is refs/heads/master. It is consistent with the documentation.
Thus, if the build is triggered by 'RepoA', Build.SourceBranch can successfully represent the true branch. However, if the build is triggered by 'RepoB', the value of Build.SourceBranch are always refs/heads/master.
We have reported this issue to the product group.
I am trying to get the "Require template" check working on a protected resource (Agent Pool, Service Connection, etc) in my Azure Pipelines.
I've got a shared template setup in a common repository (named "goldenimage-azure-pipelines-templates") that is defined as follows:
# /templates/pipelines/master.yml
parameters:
- name: templates
type: object
default: []
stages:
- ${{ each template in parameters.templates }}:
- ${{ each pair in template }}:
${{ if eq(pair.key, 'template') }}:
${{ template }}
Then I have a set of shared templates in the same repository that are referenced by the consuming azure-pipelines.yml file.
# /templates/stages/main.yml
stages:
- stage: mainBuild
jobs:
- template: /templates/jobs/set-version.yml
- template: /templates/jobs/build-image.yml
- template: /templates/jobs/cleanup-build.yml
- template: /templates/jobs/test-image.yml
- template: /templates/jobs/cleanup-test.yml
- template: /templates/jobs/update-configmap.yml
- template: /templates/jobs/destroy-template.yml
- template: /templates/jobs/cleanup.yml
Now, in my consuming repository, I have the azure-pipelines.yml file defined as follows:
# azure-pipelines.yml
name: $(GitVersion.NuGetVersionV2).$(Build.BuildId)
trigger:
branches:
include:
- master
paths:
exclude:
- 'README.md'
resources:
repositories:
- repository: templates
type: git
name: goldenimage-azure-pipelines-templates
ref: feature/WI443-baseTest
variables:
- template: /templates/vars/main.yml#templates
- template: /azure-pipelines/vars.yml
extends:
template: templates/pipelines/master.yml#templates
parameters:
templates:
- template: /templates/stages/main.yml
And then in my protected resource (Agent Pool or Service Connection), I've defined the check as follows:
But whenever the build runs, it ALWAYS reports that it has failed this check.
I've tried changing the syntax for the Ref to several different options such as:
feature/WI443-baseTest
refs/heads/feature/WI443-baseTest
refs/tags/extend (made this tag just for this test)
I've also tried adding and removing the leading slash on the path to the template, and well as adding #templates on the end of it.
In addition, I have added and removed the template on both the Service Connection, and the Agent pool (in case it would work with one, but not the other).
No matter what I do, it reports that the run is not extending the template. However, I can see in the pipeline the jobs from the template, so it's obviously pulling it.
What am I doing wrong?
No matter what I do, it reports that the run is not extending the
template. However, I can see in the pipeline the jobs from the
template, so it's obviously pulling it.
The direct cause of the issue is that your pipeline doesn't pass the Require Template check. I think the jobs are canceled because of that.
I found it could work well if all my resources were in branch whose format was feature. and same issue occurred if I used a branch like feature/xxx. So I think the second format branch is not supported well in Require Template check .
Check the pic above, according to my tests the check works well for DevBranch, but not Feature/Test. I suggest you can post a feature request here to report this issue. Thanks for your help to make our product better :)
resources:
repositories:
- repository: templates
type: git
name: goldenimage-azure-pipelines-templates
ref: feature/WI443-baseTest
the ref in the pipeline should add the ref/tags/* or at your case ref/heads/feature/WI443-baseTest
in the security approval is the same too, you may refer this article for more information here
Can someone please explain or provide documentation for
resources:
- repo: self
in the azure-pipelines.yml files? I cannot find any documentation for it.
Here's the official Azure docs:
https://learn.microsoft.com/en-us/azure/devops/pipelines/yaml-schema
"self" means "the repository that the YAML file is in".
Daniel Mann answered this question. It turns out, I did not need the repo: self part. This part is what I actually put in my YAML azure-pipelines.yml file and it is working for us. Thanks again!
trigger:
branches:
include:
- master
- features/*
- bugs/*
paths:
exclude:
- README.md
jobs:
- template: path/to/backendRepo/azure-pipelines.yml
parameters:
componentName: BackEndStuff
- template: path/to/frontendRepo/azure-pipelines.yml
parameters:
componentName: FrontEndStuff
https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/github?view=azure-devops&tabs=yaml#access-to-github-repositories
I was wondering the same, and managed to find this, that actually documents what the earlier answers describe