I have the following scenario with Bamboo/Stash:
The problem is that when the build sends the auto-merged commit to stash it does not notify it as good, but since it is the last commit Stash does not enable the merge button. As a workaround we have to run another build (run manually) of the same branch plan, but I think that should not be needed since Bamboo will build the same thing that it already did.
Is there another solution?
If you ask about pull requests automerge commit, then you should extend standard build-integration plugin to enable handling of `merge` references. Standard plugin handles only `from` references.
The idea of testing automatical merge references on CI server is not so good in fact. Imagine that you have 10 pull requests into 'master' branch to be merged after green builds. At begin, CI run 10 builds (for example, one per each pull request). Then first pull request merged, the 'master' branch was updated, and all remaining unmerged pull requests must be rebuilded. All automatical merge references will be deleted (for remaing 9 pull requests) and recreated from fresh 'master'. Then CI run another 9 builds again. And so on. (N^2)/2 builds requires to be runned on CI server for merging N pull requests, if you enable cheking for automerge commit.
Here is discussion for another one aproach, but it look like not very likelly from Atlassian side. They did not like that idea :)
https://jira.atlassian.com/browse/STASH-3903
And very long discussion:
https://answers.atlassian.com/questions/212418/reduce-of-rebuilding-automerge-commits
I'm actually trying to reduce the number of builds not the other way around.
I don't really understand the example you give about the multiple builds. Why should I rebuild the remaining branches with every merge?
A: But Bamboo already knew that commit C was good, and really is a pain, the developer knows upfront he needs to wait 2 builds that are virtually equal.
B: This build also seems unnecesary to me, unless PR2 receives another commit before merging.
I don't see the other PRs' branches rebuilding, unless they also receive commits meanwhile PR2 was building, in that case I can see the build count raising, but I doubt it will go as high as 50 as you suggested.
Anyways creating or modifying a plugin seems the best way to go.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Stash creates Automerge commit inside, it happened automatically then target or source branch changed and pull request overview page accessed buy user. But you can't merge outdated pull request, Stash will rebuild it, and creates new refs/pull-request/1234/merge reference within Git.
I can't understand what you mean about 'Bamboo merges'. Your CI merges Pull Requests within Stash? We using own auotmerge plugin for this, PR requests merged automatically as soon as possible -- all build are green, all reviewers approved, etc.
In any case, compiling on source branch of PR not allow to be sure, that merging does not brake target branch. It might be green build on source branch in unmerged PR and failed master after merge.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I think we are talking about different auto-merges. I'm talking about the branch updater described here: https://confluence.atlassian.com/display/BAMBOO/Using+plan+branches#Usingplanbranches-Usingautomaticmerging
I have the following config where Debug branch points to master.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.