Enable merge button in the pull request only after auto build success that too specific branch patterns. (branch level) ex: feature/XX_XX -->master PR only need to check the build status. If auto build is in progress, PR merge button should not enable.
Pls let
me know if any option for this.
We have 500+ developers, will not wait for auto build to complete and merge the PR which leads wrong code to master branch which is golden source code
It’s a data centre /server
Pls help me. Fyi
I don’t want minimum successful builds option because it’s a repo level.
I want at branch level… in multi branch pipeline we will only enable specific patterns., because developers volume is high. And we don’t have that much resources of build servers
This is configurable in the Repo settings -> Branch restrictions -> Add a branch restrictions. You can use either a branch name (just type the branch name) or branch patterns and check no failed builds and no builds in progress.
Related
Github has the option to allow a PR to be squashed when merged ("Squash and Merge")
Is there anyway I can configure the branch so it only allows the "Squash and Merge" option?
My scenario is this
we have a develop branch, that feature requests are pushed to
sometimes developers will forget to choose "Squash and Merge" and will commit their feature branch, with 10-20 tiny commits to the develop branch.
These changes eventually get merged to master, and feature history becomes hard to read
I have looked in hooks in branch protection rules, but didn't see any such option
Unfortunately the option to change what type of PR merge is available on Github is set on a per repo basis. Since PRs are a github thing, not a git thing, I can't think of a way that you'd be able to do anything with githooks either.
I don't see a great option for your workflow as long as you require the intermediate develop branch that eventually gets merged into master. Workflows that have multiple layers of PRs get messy on Github. The one real option would be that you require squash to merge on Github PRs and then the regular merge from develop to master happens outside a PR (could be local on a machine or via a Github action potentially).
But, your best option if this is really a big problem may be to modify your workflow. One common workflow would be that master is the development branch. Then when it is time for a release a release branch or tag, depending on your needs, is created from master. The you will have no issue turning on the repo wide requirement for squashing.
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 found how to block/protect branch from pushes, force pushes but how to protect branch from pull requests? When somebody creates pull requests branch merges with branch which locked (f.e. master branch) without any problems or acknowledges. How to protect branch from pull request Of course if it possible?
Branch lock (protect branch from pushes);
Branch security (deny force pushes)
I want to make impossible to complete pull request to locked branch. Of course if it possible.
I tested locking a branch, the result of the test is that it can successfully prevent other users from completing the pull request and merge to the target branch.
When I lock the master branch, and then create pr from the dev branch to the master branch, when I click complete, I will be prompted to stop me from completing the pr.
In addition, locking the branch can also prevent me from committing to the locked branch.
So I think locking branch can meet your need.For details ,please refer to this official document.
Plainly block branch from any PR isn't possible as a singular feature. But you can use branch policies to achieve something alike.
ADO docs says you can set policies:
Add specific person as required approver (it can be you)
Require minimum number of reviewers (you can add 999 person)
Check for linked work items
Require approval from external services (via API)
Plain locking branch forever and whatever happens is not the best approach (you want to have opportunity to do that sometimes). Hope that helps.
Hm strange. Because in our case lock not preventing from PR.
Probably it depends on who made PR. His privileges in Project but I'm not sure...
master branch lock
successfull PR
How can you stop a branch being accidentally deleted in a pull request?
The issue is the "Complete pull request" has got the "Delete dev after merging" check box, and this seems to be checked by default, which may be because I'm the owner of the repos.
Is there someway to disable this for all users?
For now, there is no way to disable the Delete source branch after merging option.
And there is an user voice Disable Delete Branch Checkbox in PR When Branch Policy In Place which suggest similar feature, you can vote and follow up.
The workaround is set branch security for the target branch (dev branch for your situation):
In VSTS Branches Tab -> click … button for dev branch -> Branch security -> change Force push (rewrite history, delete branches and tags) as Deny for the users and groups -> Save changes.
BTW: Delete source branch after merging option in PR completing window is not checked/selected by default, but based on the last time's setting. Such as if you deselect the option now, when you open the PR completing window next time, the Delete source branch after merging option will be deselected.
See this post. You just need to add a policy to the branch, then it cannot be deleted.
I may be a bit late on this thread. I faced this problem and found solution in Azure Dev Ops. While approving you get option to deselect.