I have deployed Azure Data Factory pipelines and associated components to adf_publish branch in Azure Devops. Now I want to deploy those changes to the Prod branch, but the problem is that the Prod branch and adf_publish are not in sync. When I try to create a pull request I get 100 files and 100+ commits will be merged message which is not what I want. I want to merge only 1 Data Factory pipeline which was newly created and associated datasets (8) and Linked Service(1).
I tried the cherry pick method from the adf_publish branch but it still takes everything that is missing from Prod Branch. Is there an easy way to accomplish this either through the Azure Devops UI or through Visual Studio Code.
As per the screenshot below I see + next to multiple pipelines which indicates that they are not present in Prod branch, I just want to merge 1 pipeline and leave all the rest in adf_publish.
Any help would be highly appreciated. I have tried multiple things but nothing is working. Thanks
ADF_Publish branch will generate ARM templates for deployment automatically. Those templates you will be selecting as part of your release pipeline to perform deployment.
So, after merging ARM templates from ADF_Publish branch to another branch, if you are using same ARM template files from another branch to release deployment then it should work.
If the change(s) you seek aren't in separate commits, break the commit into individual commits using the approach outlined here. You use git rebase -i to obtain the original commit to modify, then git reset HEAD to selectively rollback changes, and finally git commit to commit that part as a new commit in the history.
Another useful technique is described in Red Hat Magazine, where they use git add —patch or maybe git add —interactive to add just sections of a hunk if you wish to separate various changes to specific files (search in that page for "split").
After splitting the modifications, you may now pick and choose which ones you wish.
Related
I have a scenario where I will sometimes need to cherry-pick some commits from our UAT branch into our MASTER branch. This is because the business sometimes will request that only specific "features" are moved from UAT to production. I need to be able to pick certain commits to move forward as PR.
The issue I am having is that when try to cherry pick from one the commits (from the UAT branch) to master, Azure DevOps give me the error...
"Encountered conflicts when cherry-picking commit "42af19". This operation needs to be performed locally."
I am able to do this same pattern against my UAT, QA and Integration branches, I only have this issue against our master branch. I don't have any conflicts in the source branch so I don't believe its that. I also don't have any special rules for the master branch that should keep me from doing a UI based cherry-pick.
I really can't have our developers do this locally so I am hoping for some sort of option where they can use the UI for this.
We are using ADO to host the repo for our Salesforce code. We use another system that handles the CICD pipeline.
The high-level background for this is that we have may have 2 or more PR's that have been promoted and deployed to UAT, but the business may request that we only deploy certain ones. So some PR's might remain open against master for a few dev cycles. The issue is when other PR's move through and we need to promote them from UAT to master, ALL of the changes are getting added to the UAT > MASTER PR due to the fact that the code in the PR's that are in the holding pattern have not been committed to master, so the subsequent PR's would pick up those changes and try to merge them in, and we don't want that.
The thought is that we could cherry-pick commits from UAT as a PR. These only only contain the files we actually want to deploy, not EVERYTHING.
Hopefully someone can help me out with this scenario as I am a little stuck.
Thank you all very much for your guidance!
I have been working with a similar branching strategy for Salesforce. Normally in this situation, we would do the following:
Create a branch out of master - it will be used only to resolve conflict.
git checkout -b gs-pipeline/...
Cherry-pick a commit there, you can space separate them if there are many
git cherry-pick COMMIT-HASH1 OPTIONAL-COMMIT-HASH2
Solve Conflicts manually, save files, stage them, commit and push
Open Pull Request from gs-pipeline/... -> master
Unfortunately, there is no easy way to solve this within UI as far as I am concerned.
However, when you would down merge from master -> uat(directly or via a separate branch) that may solve your issue. It should be safe as things on master/PRD should already be on UAT and all lower environments.
I am currently building an Azure DevOps CI/CD pipeline and if it fails, I don't want to keep the code that lead to the fail in my repository. So, if the pipeline fails, I want the repo to be reverted to the last version before that commit. I can't find any help on that. How does this option look like and how can I add this option to my .yaml file?
Thank you so much.
Normally, you can use the git revert command to revert some existing commits.
In your pipeline, you can check out the git repository and the branch where you made the changes. Then run the git revert command to 'undo' some commits.
For more details, you can reference the following articles:
Git - git-revert Documentation
Git Revert
However, as #GeralexGR has suggested, it is recommended that you'd better create a develop branch based on the default branch (main/master) and make changes on this branch. Then build and test the code on the develop branch. Once everything is good on the develop branch, you can create a Pull Request to merge the changes from the develop branch to the default branch.
I want to automatically merge commits from master into another parallel branch which is used for different deployment strategy. So essentially whenever there is a change in master I want that change to be merged into one more branch automatically.
Is there a way in Github UI to do so?
Github does support automerge, but only for Pull Request.
You might check out a GitHub Action like action-automerge
GitHub action to automatically merge the source branch into a target branch every time a change is made.
You can add a GitHub Action workflow to your project in order to enable that "action-automerge".
That being said, maybe you have other approaches which would be simpler than merging master/main. Using the same branch but with a deployment script able to detect its execution environment would be easier.
I'm looking for a solution to dynamically select a branch to build in the Azure pipeline. I have Azure Repos Git where I select project, repository and default branch. I would like to be able to select branch based on a variable.
What I'm trying now is to use the Command Line task and fire a git checkout command (e.g. branch is a variable):
git checkout $(branch)
I can't confirm it working yet but still I confirm it works but I feel that there is a better option than checking out default branch and then switching branch with the command line.
Update:
If you want to have single pipeline that can build different branches (version branches) for different branches, you could just specify them in the trigger of branch filters. This will not build all branches.
The branch you select in build definition is just the default branch used when you Queue New Build manually. OTOH the build trigger establish which branch to download, e.g. if the build has been triggered by a git push on branch develop then that is the one checkout'ed and built. Take a look at this link: Get the sources from the branch that triggered the build in Team Services
Besides, you could disable the default get source step.Then use you own powershell script and git command to get source code manually(just what you want) and check out branch, finally build based on your variable.
For YAML, to disable the default "Get Sources" just specify none in
the checkout:
checkout: none
For UI, please refer my reply in this question:
Is it able to ignore/disable the first step Get source in vNext Build?
Assuming you're choosing the default branch. That doesn't mean that
it's the only branch that can be built by that build definition.
You can choose which branches to monitor for CI (on the Triggers tab,
you can add multiple branch filters to represent the branches you wish
to build on commit), and the appropriate branch will be checked out
when the build is triggered. You can also choose an alternate branch
when manually queuing the build.
Source Link: Get Sources from multiple branches
If you want to dynamically select default branch as below, this is not available at present.
This is the branch that you want to be the default when you manually
queue this build. If you set a scheduled trigger for the build, this
is the branch from which your build will get the latest sources.
The default branch has no bearing when the build is triggered
through continuous integration (CI). Usually you'll set this to be
the same as the default branch of the repository (for example,
"master").
There is a related user voice here: When triggering a build, use the same branch as the trigger build. You could kindly vote up and track the process.
I've recently transitioned from XAML builds to v.Next builds. I've always kept one build definition per branch but I see the new system has the ability for a single build definition to trigger on multiple branches and pull requests.
Is this a good idea? What are things to watch out for and the best ways to set this up?
The first couple concerns that come to mind are:
1) Version numbers. How would I handle scenarios such as an old maintenance branch versioning as 1.0., master versioning as 2.0. and a dev build as say 0.2.* so I don't confuse build artifacts? Is there a better way?
2) What if the repos tree has changed? What if master expects to build a .sln in one folder but a dev branch has since moved it to another folder?
Any other concerns and resolutions?
Single build definition to trigger multiple branches and pull request can make VSTS build more flexible. You can choose the way as you need:
If you want to build a certain branch for a build definition, you can specify the certain branch name. Assume if you only want to build master branch, you can specify master branch in Get Source step (for manually build), or specify master branch in Branch filters (for CI build).
If you want to build multiple branches in a build definition (for CI build), you can specify the branches in branch filters on Triggers Tab.
If you want to verify a PR before merging, you can add build validation for branch policy.
For your concerns:
Even a build definition can trigger multiple branches, but for a certain build, it build a certain branch after changes are pushed on this branch. And you can detect which branch is actually build, and update branch version number correspondingly.
Such as you have a build definition which can trigger to build both for master branch and dev branch. After pushing changes to master branch, a build will be queued for master branch. And you can get the branch name by some ways, so you can increase the version number correspondingly.
You can not only specify which branches can be triggered in your build definition, but also specify the folders which can be triggered in path filters. Assume there are folderA and folderB both contain .sln, you want to trigger build only when the .sln file changes under folderA, so you can specify branch filters and path filters as below:
For the situation: multiple branches can be triggered by a build definition, you can add a PowerShell task to detect which branch is building. The script as below:
$head=$(git rev-parse HEAD)
$sha=$head.Substring(0,7)
$branches=$(git branch -rv)
for ($i=0;$i -lt $branches.Length; $i++)
{
if ($branches[$i] -match $sha)
{
$tbranch=$branches[$i] -split "\s+"
$local=$tbranch[1] -split '/'
$br=$local[1]
echo "You are building $br branch"
break
}
}
This part,
Is this a good idea? What are things to watch out for and the best ways to set this up?
is off-topic (too broad/primarily opinion based), so I'm ignoring it and answering the two concrete scenarios you outlined.
Not really sure what you're asking. Release definition environments can be set to trigger on branches (artifact triggers), so if you have different release requirements for older branches, you can have different release definitions or simply an alternate pipeline within a single release definition.
You can specify wildcards in the Visual Studio Build step so you can specify, for example, **/*.sln. That will find any .sln file under any folder.