I'm trying to set up my .gitlab-ci.yml in a way that different stages get executed on commits on different branches.
I have a development, master and release branch.
I want a staging deploy to run on a commit on master and a full release on a commit to release.
I'm currently trying this:
stages:
- deploy
- release
deployToAWS:
only:
refs:
- master
stage: deploy
script:
- bash deploy/AWSdeploy.sh
deployToLive:
only:
refs:
- release
stage: release
script:
- bash deploy/liveDeploy.sh
But this only runs when I commit on my master branch, and nothing happens when I commit to my release branch.
So how do I change my file to run the release stage on a commit to the release branch?
Related
I have trigger in azure-pipelines.yaml like below.
resources:
repositories:
- repository: APPLICATION
type: git
name: AAA/APPLICATION
ref: master
- repository: TESTS
type: git
name: AAA/TESTS
ref: master
STAGES:
- stage : BuildApplication
// checkout branch & build necessary things
- stage : BuildTests
// checkout branch & build necessary things
Since the yaml resides in Application repository, While creating manual CI build I am able to select the Branches in Application repository & for Tests repository the branch checkout will be master always.
is there any was I can able to set the branch details of Tests repository before creating release ?
Is there any was I can able to set the branch details of Tests repository before creating release ?
From your YAML sample, you need to select the Resource Repo branch when manually running the pipeline.
I am afraid that there is no out-of-box method can select the resource repo branch. The branch is defined at resources field. When you running the pipeline, it will use the default branch.
For a workaround, you can change to define the repo in check out field. You can use paramter to define the repo branches and then you can select the branch when you running the pipeline.
Refer to this doc: Inline syntax checkout
Here is an example:
parameters:
- name: test
values:
- refs/heads/main
- refs/heads/test1
pool:
vmImage: ubuntu-latest
steps:
- checkout: git://azure/Repo13#${{ parameters.test }}
Result:
We have a YAML based pipeline that Unit Tests and build an ASP NET Core website then if everything is OK it deploys to DEV, TEST and eventually Live Azure Resources.
Our source control is Git within Azure Dev Ops.
Our process has us working in a branch for each feature, once those branches are ready we merge them into a "release" branch for an integration test before being PR'ed to MAIN. An example of our release branch would be "release_3_1_5".
The start of the YAML pipeline looks like this
pool:
vmImage: 'windows-latest'
# Why would I want 'resources'
# resources:
# pipelines:
# - pipeline:
variables:
azureSubscriptionEndpoint: 'ARM Service Connection'
webAppKind: webApp
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
# Change this when adding functionality that is a breaking change
majorVersion: 3
# Change this when adding functionality that is backwards compatible
minorVersion: 1
# Change this when making fixes that are backwards compatible and not adding functionality
buildVersion: 0
# Concatenate version parts and buildId to get a full build version string
fullBuildVersionString: $(majorVersion).$(minorVersion).$(buildVersion).$(Build.BuildID)
name: $(MajorVersion).$(MinorVersion).$(buildVersion).$(Build.BuildID)
stages:
- stage: Build
jobs:
- job: Build_Job
steps:
- bash: |
echo $(fullBuildVersionString)
We don't specify any explicit triggers so the build runs everytime we push to a branch.
The "MAIN" branch has some branch policies set, those policies include "Build Validation" and currently the Build Validation build policy is configured to run the same YAML pipeline.
The CI pipeline works just fine when pushing changes to our branches, except when the branch in question is the subject\source of a PR to MAIN. In this situation the pipeline starts twice. Once for the push to the "release" branch and once by the branch policy because of the PR into MAIN.
Is there a better way to configure the pipeline so it does not kick off twice? I basically do not want the CI truigger to fire when the branch is the source of a PR to MAIN but that looks like an impossible condition
This is something we struggle with as well. We have just accepted the double builds for now. However, I am starting to consider not having a build trigger for feature/ branches and only trigger for PRs.
The only other option are double manifests. One manifest for branches that are not MAIN, and the other being a manifest that includes only PRs and the MAIN branch.
If you want builds to run for branches, you could consider pre-receive hooks that requires builds to run locally.
Quite new to the CI/CD pipelines in AzDO. I was going through some official Azure Pipeline documents where I have some doubts on Schedule Triggers.
Below is a pipeline Snippet in main branch:
schedules:
- cron: "0 0 * * *"
displayName: Daily midnight build
branches:
include:
- main
- releases/*
exclude:
- releases/ancient/*
- cron: "0 12 * * 0"
displayName: Weekly Sunday build
branches:
include:
- releases/*
always: true
The documentation says the Pipeline will run for branches "main" and "releases" at midnight if there has been some changes to those branches since the last successful scheduled run and build the "releases" branch on sunday irrespective of changes to releases branch which seems understandable.
Which means we can control other branches (e.g. releases) to build from YAML file present in another branch (e.g. main).
Again, the documentation also states, for below YAML in a release branch
# YAML file in the release branch
schedules:
- cron: "0 0 * * *"
displayName: Daily midnight build
branches:
include:
- main
The pipeline won't build "release" branch since the branch name is missing under "branches" section. But will it build the "main" branch though since it's mentioned under "branches" section?
If no, then how can the first YAML in main branch make "releases" branches to build? Does the YAML file in main/default branch has some special capabilities?
If yes, does it really make sense to build "main" branch from release/non-main branches?
Thanks in advance.
If no, then how can the first YAML in main branch make "releases"
branches to build? Does the YAML file in main/default branch has some
special capabilities?
There's a setting for default branch in Azure Pipelines (Edit pipeline -> get sources -> Default branch for manual and scheduled builds) which tells the pipeline which branch to evaluate for scheduled runs. Yaml builds use the same scheduling that classic pipelines do and a changes to the yaml-file in that default branch are reflected in the scheduler.
Or to put it in another way, a pipeline in Azure DevOps is a separate thing from the yaml-file in repository. After creating a yaml-file in repo, you need to create a pipeline in Azure DevOps, via new pipeline -> select repo -> existing Azure Pipelines yaml file (or create a new yaml file). This step creates the actual pipeline, which has it's own configurations that are stored somewhere in Azure DevOps database. Those configurations point to the yaml file that is evaluated for pipeline runs and when the file is changed.
If you queue a pipeline manually, and select some other branch than the default, the yaml file in the branch that you selected is evaluated. Also, when evaluating branch triggers, pipeline evaluates the yaml file in the branch commit is made to. So, if you have this trigger in main branch:
trigger:
- main
- feature/*
And this in feature/foo -branch:
trigger:
- main
A commit to the feature/foo branch does not trigger the pipeline.
(Not sure if I answered the question clearly or just added some confusion, but there you go. The trigger implementation in Azure Pipelines is a bit confusing at first.)
When I do npm version patch && git push I want it to run a step based on a condition.
trigger:
branches:
include:
- master
tags:
include:
- '*'
...
steps:
- bash: |
npm publish
displayName: 'npm publish'
condition: startsWith(variables['Build.SourceBranch'], 'refs/tags/')
But I always get refs/heads/master for source branch.
UPDATE:
git push does not normally push tags by default.
git push --tags or git push --follow-tags will push the necessary tags. To ensure that this occurs by default
git config --global push.followtags true
However, this does not fully work either, because if you push master with tag the refs/heads/master still becomes Build.SourceBranch
So I have to push the tag specifically and ensure that the build triggers, but I'd rather avoid that.
I'd also like to avoid creating a separate pipeline with a different trigger (namely the tags) to do the build.
From the YAML documentation, it seems like that is only used for manual or scheduled builds, not a CI trigger.
tags: [ string ] # list of tags required on the pipeline to pickup
default artifacts, optional; Used only for manual or scheduled
triggers
I imagine you would only get it if you were doing something like the below to manually run a tag:
For most my cases specifically, I let the CI build run have a step that manages the tag creation rather than pushing a new tag.
I am working on an Azure pipeline for a dotnet core project that runs on Windows Self hosted agent.
I want my pipeline to use Git commands to check out the release branch and merge the develop branch into it. Next steps will be to build the release branch and deploy to intranet servers
I don’t know Git wording very good, I was using TFS for years. I use the commands below and got the logs here:
- task: CmdLine#2
displayName: Checkout Release branch
inputs:
script: |
#echo off
git checkout release
git pull develop
git status
From the logs, I understand:
It downloads the content of the develop branch because it is the default branch in GitHub, I’d rather want the release branch but I believe Azure is like that
I manage to switch to release but I have these errors that I don’t understand:
##[error]Previous HEAD position was bc94bd2 Update Staging Build Pipeline.yml
##[error]Switched to branch 'release'
I understood that pull can be used with local or remote branch so I use it to fetch and merge the develop branch to the release branch but I get: [error]fatal: 'develop' does not appear to be a git repository
Do I have to specify credentials on every calls to git?
On the last step, it fetches again the code from the develop branch and I understand why
If you could help me improve my script, that would be great,
Many thanks.
You can use git merge commands to merge branches. To merge develop branch into release branch you can use git merge origin/develop. Check the document for more information. See below example:
steps:
- checkout: self
persistCredentials: true
- task: cmdLine#2
inputs:
script: |
#echo off
git checkout release
git merge origin/develop
git status
However, it is not recommended to deploy release branch in above way. You can change the default branch of your azure pipeline to release branch and enabled the Continuous Integration trigger for release branch.
So that you can create a pull request to merge develop into release from the github UI or by using commands. After develop is merged into release, the azure pipeline will be automatically triggered to deploy from release branch. Note: the azure pipeline yaml file must exist in release branch too. See below steps:
1, To change azure pipeline branch from develop to release:
On your azure devops pipeline Edit page, Click the 3dots and click Triggers
Go to YAML tab--> Get Sources-->Click the 3dots to change the default branch.
2, Set CI trigger for release branch
In the azure pipeline yaml file, set the trigger to include release branch(You can also set PR trigger):
(Actually you do not need to follow above steps to change the default branch. You just need to include the azure pipeline yaml file in release branch and set the CI trigger to include release branch as below)
trigger:
branches:
include:
- release
exclude:
- develop #if you want disable CI trigger for develop branch
By adding the CI trigger to include the release branch in the azure pipeline yaml file. Azure pipeline will automatically be triggered on release branch when merging from develop into release branch.