I am relatively new to stash, we're currently evaulating it. What we would like to do is the same workflow which works for teamcity and github server described here: http://blog.jetbrains.com/teamcity/2013/02/automatically-building-pull-requests-from-github-with-teamcity/
In short, when a pull-request is made, teamcity is configured to watch refs/pull-requests/*/merge and creates a build from that. We want somehow to display the result of this build on the stash web interface, under the pull request details. (I successfully used this teamcity build report plugin: http://code.mendhak.com/teamcity-stash/(reports correctly the build status to refs/head/master) but it does not do anything for these pull-requests/*/merge builds).
I would like to know what does this stash plugin do, because I installed it, and I don't see any difference, I can click on accept and merge buttons, even when the build is not yet run on teamcity.
thank you. Daniel Szabo
So that plugin is actaully a plugin in Teamcity that sends statuses to Stash about every build. Stash then displays those build statuses in the commit and pull request views.
I have some bad news, currently that pull request build status is purely based off commits that _on_ the source branch. Every time you push to either the source or target branch of a pull request it moves that merge ref to a new, temporary commit. The Teamcity plugin will most likely be notifying Stash about the most recent commit that built, which is this temporary commit. Stash will not take this in to consideration when displaying the pull request, and in fact you won't be able to see it listed in commits either.
Those pull-request refs are not something that we really advertise about. They're used internally to keep track of whether the merge was successful or not (and other things). One thing to keep in mind is that the merge ref only updates when someone views the pull request, not when someone pushes to the source branch as you might expect.
If you change your teamcity build to use pull-requests/*/from instead then that will use the _actual_ commits on the source branch, which will then display in the UI as expected. The downside is that you may potentially have a green build based on the source branch, but something related to the combination of source and target branches causes the build to break when you do merge. If you're worried I would definitely be merging from the target to source branch manually, which then avoids this problem.
Does that help and/or make sense?
Bitbucket Pipelines helps me manage and automate a number of serverless deployments to AWS Lambda and this is how I do it. I'm building Node.js Lambda functions using node-lambda ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot