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.
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 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.
I have multiple projects in my git repo on Azure DevOps. I have build pipelines setup to trigger when commit occurs on the "staging" branch (which is our Develop branch). But I added an additional trigger that I thought would filter on a sub-folder of the repo. Currently there are three pipelines all set to trigger on commit and sub-folder. And all three run even when there is a commit with files from only one of the target sub-folders.
See the screen shot of one of my triggers:
Seems like the triggers are setup like an OR not an AND. So, in other words any commit to staging will trigger all three builds, but there are times when I don't want all three to build and publish. Just the one that I fixed should be built and published.
Is there any way to fix this?
You're right in that both Branch and Path apply. See here: https://learn.microsoft.com/en-us/azure/devops/pipelines/build/triggers?view=azure-devops&tabs=yaml#multiple-pipelines-triggered-on-the-same-repository
Consider migrating to yaml based builds, and set up each build in a different yaml file with it's own path triggers. Not only will this solve your issue, but you'll have the benefits of checked-in pipelines.
We are following gitflow model in our project using Azure DevOps Services. I have a classic editor based pipeline which builds the Dev and Release/R1.0 branch.
I am going to setup a classic editor based pipeline which will build my Release R.10 from the master branch after merging Release/R1.0 branch at the end of the release. Let us say this classic editor based build pipeline is MyProduct-R1.0
After the release, I will be tagging the master branch and deleting the Release/R1.0 branch as per GitFlow model. However, I will be retaining the build pipeline MyProduct-R1.0
My question is this: Suppose after the Release R1.0 once master branch has moved ahead and I want to do a build of master branch at R1.0 tag, how do I do using the MyProduct-R1.0 pipeline which was used to originally build the R1.0 release?
I know this is possibly a confusing question, but I have tried my best to give it a shot.
Thanks,
Update 2: I think my question is more about the branch specification for my MyProduct-R1.0 release pipeline. I can't give master since master will evolve after the Release R1.0. I can't give Release/R1.0 since this branch will be deleted after the Release as per gitflow model. So what branch specifications should I provide for my pipeline?
Use YAML builds. There's no mechanism for this with JSON ("classic editor") builds, since JSON builds are versioned separately from source code.
Like Daniel said YAML is the best path. Handles this gracefully as the Build definition lives with the branch.
In the past for GUI builds, when I dealt with build definition drift, instead of creating new build definitions, I would use conditional steps tied to the branch that was being built, but it can be painful to go back and update\maintain.
I think here is what will achieve what I am after. Once I do my release and tag it as R1.0, then I can always use my pipeline at a later date to build the same source code in the master branch for R1.0 using either it's tag or the commit it.
Note that this shows Dev is my default branch for this pipeline as it is not yet the Release pipeline which I depict below. I am yet to create it.
Am I missing something?