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.
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.
We are getting cases where our Work Items are getting included in many builds and without sufficient documentation I can't seem to work out why. Wondered if anyone here could shine any light on this.
Example scenario is
We run "Release Flow" branch strategy (like MS describe they do for Azure DevOps)
Bug 30368 was linked to a feature branch and got back into master via PR 2991 and commit cb9120d0.
All the appropriate links to PR and Branch were in place for this so both the PR and the master commit show the link to the work item correctly
We create our release branch off of master and 30368 was included in v2.97.0 build pipeline and was linked (correctly) with an "integrated in build" to that build
Build 1 is created
We then had a bug in v2.97.0 during release testing (not to do with Bug 20368) and so we Cherry Picked the master commit with the fix into the release branch (as per Release Flow guidance).
I'm wondering that this Cherry Pick is the cause of the problem I describe later
Of course the work item wasn't included in this second build of v2.97.0, only the work item with the related fix was
Build 2 is created
So all is good so far. v2.97.0 release is deployed from Build 2 and all the links are correct
Now we branch from master for v2.98 release and the release pipeline does another build.
Build 3
For some reason it determines that 30368 should be linked to this build also and adds a "integrated in build" to the v2.98 build?
The only other clue that I've found is to do with the commits that are linked with the build. Here I can see that I get the following
Build 1
from e0faff8f (master 2019-12-02 commit release 2.97 was branched from )
to db225f14 (from feature branch just before PR completed 2019-11-21)
Build 2
from aeaf3dc5 (release branch 2019-12-03 cherry picked)
to e0faff8f (pull request branch 2019-12-03)
Build 3
from f2ce6d3d (release branch 2019-12-06)
to f3db8c7b (2019-12-02)
It isn't even clear to me how the build pipeline knows what the range of git commits are included in it and perhaps this is the key to understanding the link. Of course it gets the From part from the commit that the build ran from but how does it know which commit it should go to?
Also in the above example, neither the range given for Build 1 or Build 3 seems to have the commit that is related to the item (cb9120d0) in it - even though this work item has been linked to these builds?
It is all pretty confusing and nebulous.
Has anyone got this feature working correctly/reliably?
I also wondered if we need to create specific pipelines for each branch so that each branch is independent but I'm not sure as even if you create a brand new pipeline and point it to the master branch it doesn't include every single commit ever (and workitem) in that build. Again, how does it know where to start?
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.
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
Describe the process you use to develop web applications at a not-so-high level, focusing on VC, bug tracking, QA, unit testing, deployment and anything else similar (minus the planning/client communication side of things).
I'm new in this area, so my rough example (read: haven't used this process) is no doubt abit off, so to speak - point out it's flaws so I can learn.
Eg.
Create project repository on local SVN server.
Create batch/shell scripts for DNS mappings.
Check out project, begin work on local working copy.
Develop features as branches.
Track bugs with Mantis (link commits to bugs through it's SVN integration (no idea if that exists)).
Document as you go.
Do QA on branch.
Merge to trunk when stable.
Unit Testing?
Commit to repository when feature is implemented and stable.
Copy releases to tags in repository. Eg. /project/tags/rel-123/
Use Phing to upload to staging server. (Could someone please clarify exactly what a staging server is used for beyond 'testing'?)
Use Phing to prep live site for update, set up DB/deploy, etc.
Create/checkout HEAD version ("main branch")
Develop code and sync with the main branch -at least- daily
After development is done, write and run unit tests
Go through code review and submit code/changes to the main branch
Let continuous builder run all unit tests and system/integration tests on main branch
When ready, cherry pick revisions and integrate them to the QA branch
Run system and integration tests, fix reported bugs, or rollback as necessary; this repeats steps 4-7
After QA signoff, integrate QA change to release branch
Run unit tests, system/integration tests on release branch
Deploy to production and run sanity tests.
A staging server is a copy of your production environment that is as up-to-date as possible. On my current project, we're able to keep each release independent from each other, so our "staging server" is our production server, just accessed from a different url.
Notes and discreprencies:
All of the steps have some variation depending on the size of your project. The larger your project, the better the benefit from cherry picking and environment separation. In smaller projects, these can just be time sinks and are often ignored or bypassed.
To clarify, there is a Development stack, QA stack, and Staging stack. Depending on your project size, QA might be staging, Production might be staging, or some combination thereof. The separation of the Dev and QA stacks is the most important one.
In the steps above, I'm assuming both code and relevant data is versioned or tracked. Having a release and build process that takes control data into account makes a release very, very easy.
In a small-medium sized project, there may or may not be a release branch; it depends on the frequency of code change. Also, depending on the frequency of code change and size of your project, you may integrate the full QA branch to the Release branch, or cherry pick specific revisions to integrate to the release branch.
FWIW, I've found "migration scripts" to be of little value. They're always a one-off script with little reuse and make rollbacks a pain in the ass. Its much easier, I would argue better, to have the application backwards-compatible. After a few releases (when a rollback is a laughable), data cleanup should be done, if necessary.
Very roughly:
Create repository in SVN
Checking local working copy to developer environment
Update/commit changes frequently
Deploy to stage from SVN trunk using custom deploy script
QA tests on stage, reports bugs in Mantis
Developers fix bugs, mark as resolved
Re-deploy to stage
QA tests bugs, closes if fixed
QA is finished, do regression testing
Deploy to production using custom deploy script
Do a little dance
We also create branches for future versions or features. These eventually get merged into the trunk.
We keep our db structures synchronized with a custom db comparison tool that is executed during the deploys.
Old post, but interesting question !
At my company now :
Create a new Github repo
Configure Jenkins
Clone locally
Start a branch
Develop and add tests (server, client and e2e)
Commit for every step, and fetch + rebase to keep the branch in sync
When ready, push the branch to the server : a pre-commit check lint and tests and block if not ok
Create a pull request for the branch
Here, jenkins automatically runs tests on the branch and flag it as "green" or "broken tests" directly in the pull request
Have at last 2 colleagues review the pull request and fix their findings (back to step 5)
When everything green and 2 colleagues have agreed, the last one merges the pull request
Delete the branch on server
When ready, push a new version
Latest version get immediately deployed on a testing platform
QA validate the corrections and features introduced (back to 5 if problem)
(TODO) deploy to a pre-prod with identical parameters than the production
Deploy to production
Go apologize to users for the bugs introduced ;) and report them in the issue manager
get feature requests and report them in the issue manager
restart cycle at step 2