The final stage of our release pipeline is a manual stage used to confirm the deployed release got its final acceptance. Among the tasks we would like to run in this stage:
Tag the develop branch with the release label. Say "1.2.3".
Merge the develop branch into the master branch.
(We're using Azure Git repositories)
Although it looks like the right moment to make these changes in Git, I'm not quite certain this is the intended usage of Azure release pipelines. I confess being a bit new to Azure pipelines and there seem to be no evident pipeline task for doing such changes.
However, I believe this kind of post-release SCM changes is quite common.
My question is therefore: Where and how is the proper way to apply those SCM changes in Azure Devops ?
EDIT: I could make it work to use a command line task to run git commands. Config was passed by means of a variable group.
You can just do the regular git commands in a Command Line script (first , clone the repo (or add it as an artifact), then tag/merge).
Or install the Tag Git on Release & Git Merge extensions and use them.
Related
I have a continuously triggered Azure DevOps release definition that deploys a compiled Angular app to a web server and also runs Cypress e2e tests. The Cypress tests must run against the source code, so that means I need an artifact that is able to reference the same commit that was used to create the compiled app.
I created a GitHub artifact that gets the source code, but I can't figure out how to automatically change the branch/commit to whatever was used for the compiled app (it could be any branch and the names are not known ahead of time). Azure forces me to enter a hard-coded branch name and it does not accept wildcards or variables.
If I could simply use the variable ${Release.Artifacts.{alias}.SourceBranchName} for the default branch, I think I'd achieve my goal. Since Azure doesn't allow this, is there an alternative approach that accomplishes the same thing?
Note 1: The "Default version" dropdown has an option "Specify at the time of release creation", but that is intended for manual releases and can't be used for triggered ones, so no luck there.
Note 2: I looked into publishing the source code as an artifact, but it currently has almost 70,000 files and it adds more than an hour to the build step, so that also is not an option.
When you use the Release Pipeline artifacts, you are not able to set the pipeline variable in the Default branch field. This field only supports hard-coded.
is there an alternative approach that accomplishes the same thing?
The variable:$(Release.Artifacts.{alias}.SourceBranchName) can be used in the Release Pipeline agent job.
Workaround:
You can remove the Github artifacts and then add a Command Line task/PowerShell task/ Bash task to run the git command to clone the target repo.
For example:
git clone -b $(Release.Artifacts.{alias}.SourceBranchName) GithubRepoURL
PowerShell sample:
In this case, the script will use the same branch as Build Artifacts to checkout the source code.
I have a build pipeline that I want to trigger when the workspace_publish branch has changes to it, which is fine and this is currently working using these settings:
However, I want the Agent to extract the SQL Scripts (on the second step) from a different branch in the "Synapse Reporting" repository, NOT the workspace_publish branch.
Is this possible?
Actually this is fairly simple. You simply add another artifact to your pipeline that points to the source control branch you are interested in:
You then have 2 artifacts that are copied over and can be accessed during your release process.
TL;DR
How do I avoid rebuilding artifacts on master when a feature is merged without creating multiple pipelines per project? Where do I access the information about which branch was merged?
More Info
I run Jenkins to build many projects stored in two different VCSs (Gitlab, Bitbucket). Auto-discovery for both VCSs work and create multi-branch pipelines for every project/branch/PR containing a Jenkinsfile (Gitlab Branch Source Plugin, Bitbucket Branch Source Plugin).
Build artifacts get produced and stored on every build (e.g. docker images pushed to registry).
As I follow a feature branch workflow, these features get eventually merged into master, master will then be deployed in irregular intervals.
When doing the merge, there is an artifact already built and stored for this code(see appendix:1). It was built for the feature branch the code originated from (e.g. container mysuperapp:feat-add-better-things-3). I would like to take this artifact and promote it as the new master artifact (e.g. mysuperapp:master), avoiding a rebuild (and unit + integration testing everything).
But, merging a feature branch just kicks off a new build pipeline on branch master without any information about the merged branch (see appendix:2). This is correct behavior concerning master (new commit(s) where pushed) but prevents me from reacting to the merged branch (e.g. the aforementioned promoting or even just deleting unused artifacts). Is there any way to get the information, which branch was merged?
I am aware, that I can create a new pipeline listening for PR webhooks from my VCSs, running a pipeline to do the promotion and ignore builds on master completely. But this moves visibility of this process to a different pipeline and requires additional pipelines for projects, e.g. reducing the advantage of auto-discovery to 50% (have to create these merge pipelines for each project).
How can I keep the advantages of auto-discovery and visibility of executed steps while also executing something on a merge?
Ideas: Tag artifacts differently, but how (needs to be able to clean up correctly)? Parameterize pipelines and setup a single merge pipeline which re-triggers the pipeline 'push on master' with parameters of the merged branch. But can this be done without having to setup the webhooks for every project? Ask the VCSs via REST about which branch belonged to a commit?
Greets and thanks for the help you all! This may be a complicated one, but it would be so cool to get this to work. It's the last barrier for me to enable continuos delivery for a lot of projects!
Appendix:
1: I am also aware, that to have consistent builds, I have to enforce --ff-only merges. This question is not about the pitfalls of git but rather about the way to go with Jenkins.
2: Git provides me with the parent commits, I can easily find out, which commit was merged. But, especially using "Delete branch after merge", leaves me without the branch ref in git. Tagging my docker images with commits instead of branches leaves me with backtracking the last commit on each build to delete the old, obsolete build.
I'm trying to setup a library project using DevOps. The branching strategy choosed is git-flow in order to have use git version and follow semver with releases and hotfixes.
So i tried was to protect both develop and release branches by activating pull requests.
Everything works fine unless a release is going to be closed. Here I see two problems:
In git-flow the system try to realign develop from master, but devops doesn't know this is git-flow and just merges release to master.
Develop branch is protected, so if i want to realign manually i should create a new pull request, from master to a feature branch in order to solve conflicts
I'm not sure about the correctnes of the implemented workflow. Is there a better way to accomplish this realignment?
Any suggestions are welcome
Thanks
At present, azure devops is designed like this. Devops can only be one-to-one branch merge at the same time.The release branch cannot be merged into the master branch and into the develop branch at the same time.
When the release is finished, the release branch is merged into master
and into develop too, to make sure that any changes made in the
release branch aren’t accidentally lost by new development.
This feature described in git flow cannot be implemented in azure Devops.
So, your understanding is correct, you can do it manually by your method, although this may be a bit inconvenient.
We are using GitHub as our source repository, AWS CodeBuild to compile the code from GitHub, Elastic Beanstalk to host environments and CodePipeline to trigger a build on commit and to deploy the code to different environments, with production being the final environment.
What I would like to add as a final step to CodePipeline is a merge back to master after a build has been deployed to production. I did a brief search on google but could not find any good references for how to initiate a git merge.
Does anybody have any experience with triggering a merge from CodePipeline?
Currently there isn't built-in support for merging.
Today most users run their pipeline on master, and merge into that before the code enters their pipeline. One advantage of this approach is that it ensures your pipeline is run on the exact merged version on mainline, rather than a pre-merge version.
However, we're aware that some workflows like a pull-request based workflow would benefit from being able to merge at the end of a pipeline.
The best workaround today is to use a Lambda function, custom action, or CodeBuild step to perform the merge.