nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Reduce of rebuilding Automerge commits

Alexey_Efimov

In our company we setup CI integration server to montoring of 'refs/pull-requests/*/merge-clean' references. This cause incremental updates on everyone pull request is merged.

So, does Stash have ability to build Pull Requests merge queue for Automerge commits. For example, you have 10 pull requests, first build Automerge commit #1 on master, second build Automerge commit #2 on top of Automerge commit #1, and so on.

If all pull requests is green on CI server, then all of them can be merged by simple fast forwarding without rebuilding automerge commits.

If someone pull requests is failed, then you remove it from queue and append into tail. Then rebuild entire queue once again.

This will be reduced number of rebuilding Automerge commits. And as results builds on CI servers.

How do you think, is it possible to write such requests to JIRA of Stash?

Accepted answers

cofarrell

Hi Alexey,

Let me see if I understand what you're asking for - you basically want Stash to use our 'merge-clean' commit when you actually merge, instead of creating an entirely new changeset? For that specifically the best place to ask is as a feature request. I don't beileve there's any technical reason why we don't do that - it's just the way it is.

Cheers

Charles

PS. Just as a heads-up, we plan on changing/reducing the number of exposed pull-request refs. In particular 'merge-clean' is going to replace 'merge' in 2.9 (which is not for at least a few weeks yet).

All comments

cofarrell

Hi Alexey,

Cheers

Charles

cofarrell

As Bryan just pointed out to me, there is a good reason why we don't do this - Stash doesn't know which author to use. Anyone (with permission) could potentially merge the pull request and the Git author really needs to reflect that fact.

Sorry Alexey.

Alexey_Efimov

Hello Charles,

Basically my question about what: https://jira.atlassian.com/browse/STASH-3903

How Stash rebuld Automerge (merge, merge-clean refs) if 'to' reference is changed. This can be improved if you will use merge queue, and build Automerge commits on top of previous PR Automerge commit and so on.

cofarrell

Hi Alexey,

I'm not 100% sure what you mean, but I get the get the general idea. I suspect Stash's automerge is never going to do exactly what you want. Honestly, they're really an internal detail for us to make pull request diffs accurate and fast, nothing more. It's unlikely (I can't speak as authority though) that we will change them in strange ways to support the workflow you're describing. As mentioned - we want the final merge to be done again when someone finally clicks the button - that will never work with your approach.

My suggestion is manually make your own merges where you need them, and bulild those instead of merge-clean. It sounds like you might have a plugin that does something like that - and that will always be a safer approach, rather than relying on Stash's implementation details.

Sorry.

Charels

Alexey_Efimov

Bryan, you are talking about the same things what i have described in previous comment. But you also tell what i'm wrong, and then you put the same thoughts Okay. Stash will sit and wait until someone open Pull Request page and then rebuild it. Or until Automerge plugin try to merge it. No matters.

I totally not understand your second comment. I know what you know Git So, mergin from_1 + to_1 makes a branch where presented commits from both branches, and then if you will use merge_1 as to_2, it will be work just the same way as Stash works now.

The only one difference. Now Stash merges all pull requests parallely, my suggestion is option to make Stash merging process through queue — serially. In small repos with a few pull requests parallel did not force build storm, but in large repos with many pull requests active queue will have a profit. Because you only need to rebuild tail of queue, not entire queue if some build is fail in middle of queue.