We are utilizing Azure Devops (TFS) build pipeline for managing a Git Repository/branches/stages (Dev/test/prod) and one thing that came up is the concept of "cherry-picking" commits. However, the user would have to supposedly look at the commit hash code and pass it in as argument to deploy that specific commit should a use case scenario arise like that.
The project manager has asked if we can make some sort of GUI pop-up at a certain step of the build pipeline that displays the list of these commit hashes and allows a user to check the boxes for the ones they'd want to cherry-pick and deploy.
How can that be done? we are considering utilizing Java with TFS/Azure Devops API's, but not sure if we can pop-up something like that on the Azure Devops page mid-pipeline deployment.
Build pipeline is not user interactive while running. So you can not pop up a gui on a build pipeline.
If you want to check the commits and pass the commits to build pipeline to build. You can first go to the Commits under Repos and check for the commits of a branch.
Then when you queue your build pipeline. You can click the dropdown menu for Branch/tag, select Commits, and then enter the commit id you get from above step. The build pipeline will then build the commit you entered.
Related
I have a Github and Azure Devops classic editor pipeline. I want to configure an auto-trigger of Azure pipeline after a commit happened in Github (If any commit happens in the repository, it needs to trigger my Azure Devops pipeline)
I tried configuring Continuous Integration in pipeline level, and it does not trigger my pipeline after a Github commit.
Many documents are for yaml pipeline but we need for classic editor pipeline. Could someone provide your inputs on how can we achieve the same ? Thanks!
You are looking for CI/CD triggers, you can simply choose the proper branch in the build trigger combo box.
"In the classic editor, pipeline triggers are called build completion triggers. You can select any other build in the same project to be the triggering pipeline.
After you add a build completion trigger, select the triggering build. If the triggering build is sourced from a Git repo, you can also specify branch filters. If you want to use wildcard characters, then type the branch specification (for example, features/modules/*) and then press Enter."
Source: https://learn.microsoft.com/en-us/azure/devops/pipelines/process/pipeline-triggers-classic?view=azure-devops
if you are looking for deployment triggers you can find more info here:
https://learn.microsoft.com/en-us/azure/devops/pipelines/release/triggers?view=azure-devops
release trigger snapshot
The configuration of #Bayoudhi Bilel is correct, after you select the Github as resource for Class editor pipeline, enable CI trigger in "Triggers" tab. (official doc here)
Check on my side, it works fine:
If your setting doesn't work, please firstly check if you have select correct branch to monitor. If it's correct, you can follow below steps to reconnect between azure devops and github repo.
Delete all webhooks on github repo setting.
Then edit your pipeline, go to "Triggers" tab, "restore" the webhook.
change to a new service connection(it's recommended to regenerate the github PAT, you can simply add all scope):
In my Azure devops, i did it by going to pipeline > Triggers tab and i activated "Enable continous integration". You can also configure the branches you want to build from.
It worked for me this way.
Please find screenshot attached.
I have four environments that I deploy to.
I also have four different code branches that we use to deploy code from.
We constantly switch the branches we use to deploy on these environments.
One time I want to build and deploy a daily branch on my test environment.
Later I want to build and deploy a enhancements branch on the same test environment.
Next I want to build and deploy the daily branch on my test2 environment.
I think you get the picture
We are currently using a manual process to pull from the branch we want deployed, then zip it up and push it to AWS code deploy.
Using Azure DevOps pipeline and release what is the easiest method to allow me to switch to use different branchs on different environments.
I currently have a successful setup in Azure DevOps that performs a gradle build, creates the artifact and then lets me push it over to AWS CodeDeploy on one of my environments. I just can't seem to figure out a way to eastily swtich the branch without creating tons of Azure pipelines and releases.
Thanks all!
Where you manually trigger a build pipeline by clicking Queue or Run Pipeline, A new windows shown as below will be prompted which allows you to switch the branches.
If you want to automatically deploy different branch to different environment. You can push the build artifacts over to AWS CodeDeploy in a release pipeline and set the branch filters. Please refer to below steps:
1, set branch filter in the build pipeline as shown in below screenshot which will build the selected branched. Check here for more information about triggers.
2, create a release pipline to push build artifacts over to AWS CodeDeploy.
And Set the Artifact filters which will only allow the artifacts built from the specified branch to be deployed to this tage.
You could use a queue time variable to specify the branch name you would like to use on your build pipeline. You would need to:
Edit your build pipeline and create the variable on the "variables" tab. Make sure to mark the "Settable at queue time" check
variable creation
Update the source of your build pipeline, to specify the new variable under the "Default branch" option. It would look something like this:
pipeline source
RUN your pipeline. Before finally clicking on RUN, you will be able to specify the desire branch:
set variable value
Hope this works
I have a TFVC project with about 4 branches. I need to somehow setup build and release pipelines that build an artifact for each branch. Because I will eventually need to repeat this process elsewhere, I would like to prevent having to duplicate the same build pipelines for each branch. I am able to configure a single build pipeline that works on whatever branch I need using a user-defined variable when the pipeline is kicked off, but now I need to enable continuous integration on the build.
My current build pipeline trigger configuration
I need this to work such that whenever someone checks into one of the TFVC branches, the build is kicked off and can correctly identify which branch was updated. From what I have found, this means that my initial idea of a user-defined variable is not going to work any longer. Is there a predefined pipeline variable that I can use to tell which branch was checked into, so that that branch is the one that is checked out and built? If not, is there some other way to do this in one pipeline, or do I ultimately need to duplicate this build pipeline for each branch?
Sorry, it's not available with TFVC in Azure DevOps/TFS build pipeline.
For CI trigger, you could select the version control paths you want to include and exclude. In most cases, you should make sure that these filters are consistent with your TFVC mappings on the Repository tab. It's not able to dynamically set workspace mapping path based on the branch which continuous integration trigger your build pipeline.
You could also take a look at Daniel's explanation in this question: When my TFS build is triggered by a branch-specific check-in, why doesn't it set that branch as its source?
TFVC relies on workspace mappings to know what to download. The workspace mappings can encompass multiple TFVC repos across different
team projects, multiple branches within a single repository......
As a result, there's no way for it to understand how to dynamically change workspace mappings to be for a specific branch.
Conclusion: You may need one build for every branch, duplicate the pipeline simply change the path filters in trigger and workspace mappings.
Is there a way I can set up a build in Azure DevOps to automatically run every time a PR is merged and completed and contains a specific keyword in the name? for example: "Some PR name here [RUN_BUILD_123]"
Edit:
The reason for this is because I have different builds on top of the same branch so instead of triggering all the builds I just want to trigger those that I know need to be rebuilt based on the particular projects getting changed.
A PR has a target-branch. If you want to trigger a build after a PR is completed just configure a build with a ci-trigger for that target-branch. You can't check for certain keywords in the PR-name unfortunately
Agree with D.J. For detailed setting, you can check the Enable continous intergration option in the Triggers settings, then select the target branch you want ci-trigger build in the Branch filters.This will automatically trigger the build after pr is completed.
But you can't do it if you want to include special keywords in pr name.
Topic is a bit old, but if there is anyone who want's to archive this stumbling over this topic - here is my approach how I would solve this:
The basic of all are scripted pipelines, so if you still do it in the GUI - that's wasted time. Create a .yml build and put it into your Git. The M$ documentation is really helpful with this.
Create the trigger for your branch
Put this on the first line, so the pipeline will be executed when master (or your branch) has a new commit
trigger:
branches:
include:
- master
Read out the commit message via the VSTS variables
Trigger the builds, based on their ID via REST API (you can use the pipeline token for authentication)
I have branch validation in the form of a PR Build, which means I have duplicated my original build and removed some steps (such as pushing to my docker registry).
I would prefer to simply be able to automatically add a tag / some kind of identifier to a PR build and exclude the step on the original build using custom conditions.
Does anyone know if this is possible, and if so how to achieve it? I'd really rather not duplicate each and every build.
If I understand your question correctly, you would like to run a build step based on a custom condition. In this case, the custom condition is whether the build is a PR build or not.
You can check the pre-defined build variables available in Azure Devops here and you can see that there is a Build.Reason variable.
I am listing a few variables here.
Manual: A user manually queued the build.
IndividualCI: Continuous integration (CI) triggered by a Git push or a TFVC check-in.
PullRequest: The build was triggered by a Git branch policy that requires a build.
You can specify the condition in custom condition settings of your build step like this.
More examples available in the docs