I'm using a build policy on one of my Azure DevOps git branches.
Is there any way of requiring a manually triggered branch build policy be run again if the source branch is updated?
My branch policy is set to Manual trigger. We use Manual instead of Automatic to reduce the number of builds (we use self hosted build server) running on our CI server as we typically open PR's early to provide feedback and facilitate conversation around code.
If the trigger was set to automatic, then any time source branch is updated a new build is queued. This isn't case with Manual. I had situation where build policy passed but then a further commit was made to branch and the reviewer approved. But the build was not manually triggered again and the last commit & push introduced a bug. I'd like the build validation policy to either reset or fail every time the source branch is updated similar to how code reviewer votes are reset after a push.
Is this possible?
I do not think this is currently possible, it has been raised on the Developer community as a feature request / issue, so I would encourage you to up-vote this here.
A solution for our scenario (too many builds were being queued, because Code Reviews come back with changes) was to use Pull Request drafts.
Sprint 143 - Draft Pull Request
When creating a PR, you can click Create as Draft in the drop down beside the Create button.
Related
To keep it short, I'm using a script in Azure DevOps that generates a pull request automatically every time a new branch is pushed to the repository.
Said script enables the pull request "auto-complete" funcionality, which lets me merge code using GIT after I complete all the branch policies. I have only one branch policy enabled, which compiles my code and checks whether it should complete the pull request or not, based on the pipeline compilation results.
Everything was working fine before one week ago, people pushed their branches normally and ADO automatically created the PR, build checked, merged and auto-completed the PR, as my only branch policy had always been met.
Now even all branch policies are met, the PR is stuck and won't auto-complete for some reason, even after the build compilation turns out as success and there are no merge conflicts.
If I click on approve, it then begins to complete automatically as it should. However, this manual step was never necessary for the PR to finish, nor I have a branch policy that demands an approval to complete the PR.
This is affecting all the projects in my ADO organization, so it may not be a configuration problem.
Maybe anyone has stumbled across the same problem?
Edit: Microsoft is looking at the issue: https://developercommunity.visualstudio.com/t/Pull-Request-doesnt-automatically-compl/10082816
Based on the link provided in the question, this issue apepears to have been fixed on Jul 28, 2022
"Microsoft Solution - Feedback Bot
Closed - Fixed
We have released a fix for this issue! Thank you for providing valuable feedback to help improve the product."
You could check if the user account has the permission: Bypass policies when completing pull requests.
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)
We have strict build expiration enabled on our pull requests in VSTS and block PRs from completing until a successful build has been achieved. This works well and keeps our master branch clean. However, a source of significant frustration that we regularly face is when we have multiple PRs queued and which ultimately expire due to a PR which is ahead in the queue being completed.
Consider the scenario:
Developer A creates a new PR (with auto-complete turned on) which queues a new build
Developer B creates a new PR before Developer A's PR build has completed which queues another build
Developer A's build passes, the PR auto-completes and the changes are merged into the master branch
Developer B's build starts, completes and passes
Developer B's build expires as the master branch has been updated since the build was queued
Developer B has to re-queue their build...
We face the above problem almost daily and usually have several PRs backed up in the build queue. Our PR build takes ~1 hour to complete as it conducts extensive deployment and testing of the system. This leads to many hours of wasted build server time and some very frustrated developers.
Does anyone know of a way to avoid the above happening. It seems that an option to automatically remerge a PR whenever the master branch is updated would fully solve this issue.
There isn’t the automated way to avoid that in VSTS, you can change the build policy to expire after XX hours.
Go to version control admin page
Select a repository=> A branch=>Branch Policies
Click Edit of a build definition in Build validation section
Select After hours if master has been updated option and specify the hour.
Is it possible to merge pull request automaticaly to master branch on github after success of travis test webhook?
You can use Mergify to do this.
It allows to configure rules and define criteria for your pull request to be automatically merged. In your case, setting something like "Travis check is OK and one reviewer approved the PR" would allow the PR to be automatically merged.
(Disclosure: I'm part of the Mergify team.)
You can most probably add an after_success action to your .travis.yml that would merge the PR using GitHub API. I do not know of any ready to use script for this, but there is no reason for it to be hard. Special care needed for authentication ...
GitHub recently shipped this auto-merge feature in beta. To use this, you can enable it in the repo settings. Just keep in mind you will need to add branch protection rules as well.
See the documentation for more info.
https://docs.github.com/en/free-pro-team#latest/github/collaborating-with-issues-and-pull-requests/automatically-merging-a-pull-request
I work on a project that requires pull requests to be up to date with the target branch, and also to have passed all the checks before merging.
This means we can often be waiting for checks to finish, only to find a new commit has been made to the target branch, which requires the pull request to be synchronised and the checks to run all over again. I wanted a simple app to merge the PR automatically once the checks are successful, so I created one.
Mergery is:
Free, including for private repositories.
Fast. It's event-driven, it doesn't run on a schedule.
Simple. No configuration required. Just label your PRs with automerge.
Currently, my team is using TeamCity to automatically build pull requests from GitHub.
We have a configuration to build all the pull requests. In the version control settings of the config, our branch specification is
+:refs/pull/*/merge
In the "Build Triggers" configuration setting, we have only one trigger with the following trigger rule:
+:root=Pull Requests on our Repository:\***/*\*
"Pull Requests on our Repository" is our VCS root name.
The issues:
When someone views a pull request on GitHub website without doing anything else, a build would be triggered in the TeamCity build agent. This is quite annoying, because from time to time, we have multiple build agents building the same pull requests (when multiple people view it).
When someone comments on a pull request, a build would also be triggered.
From my perspective, the only time I want TeamCity to start a build is when new commits are pushed to the pull requests.
Is there a way to do it?
Github's refs/pull/*/merge branches are updated every time mergeability of the branch is recalculated, i.e. on every commit to destination (most likely master) branch. They are also updated when pull request is closed and then reopened. Github's support says these branches are not intended for end users use. The only workaround at the moment is to run builds on refs/pull/*/head branches automatically and on refs/pull/*/merge branches manually.
Do you have TeamCity configured as per this blog post? I then activate the TeamCity service hook in GitHub which takes care of triggering a build in TeamCity whenever there is a push. This seems to do the right thing for me. Or am I missing something?
I know this is old but I wanted to post what we've found as alternatives:
Stop using VCS roots altogether as a mechanism for triggering pull requests. Instead, configure a GitHub webhook to notify a web app of yours whenever there is an update to a PR and only then trigger a build via the TeamCity REST API.
In your build config, add a step that checks what changed in the PR. If nothing changed (i.e. no new commits were added), or if the PR is closed, cancel the build. The problem with this is that the build queue will still be populated with builds that will then be cancelled. Also, you'd have to store somewhere the last commit that was built in order to do the check.
According to their TeamCity's issue tracker, the issue of the TeamCity.GitHub plugin causing an infinite loop of builds was fixed in v9.0