When Automatic Merge is updated?

[Dana]

I need to operate with correct symbolic refs of PR inside my plugin:

> pull-requests/123/from

> pull-requests/123/merge

But there is a little delay, when fromRef of PR was updated by user push.

One can see it if compares result of

PullRequest pullRequest = //initialized some way
pullRequest.getFromRef().getLatestChangeset()

And the commit of pull-requests/123/from in git repo.

As we have investigated the call of calculating effectiveDiff for PR updates symbolic refs:

* Resolves the effective diff for the {@link PullRequest} provided when it was constructed. Resolving the effective
* diff may require creating or updating the automatic merge that is the basis for the effective diff.
 @NotThreadSafe
    private class EffectiveDiffOperation extends AbstractOperation<GitPullRequestEffectiveDiff> {...}

So we have decided problem with the "synchronization" by calling effectiveDiff().

But it seems to be a wrong way, because symbolic ref updating is just lateral result of effectiveDiff calls the method "maybeCreateSymbolicRefs(pullRequest, merge)".

As written in EffectiveDiffOperation class:

* <ul>
     * <li>{@link PullRequestRefs#getFrom() from}: The {@link PullRequest#getFromRef() from ref}'s hash when the
     * automatic merge was last updated</li>
     * <li>{@link PullRequestRefs#getTo() to}: The {@link PullRequest#getToRef() to ref}'s hash when the automatic
     * merge was last updated</li>
     * <li>{@link PullRequestRefs#getMerge() merge}: The automatic merge. Note that, if the automatic merge fails for
     * any reason this <i>may not</i> be an actual merge; instead, it will contain the {@code git merge-base} between
     * the {@code from} and {@code to} refs</li>
     * </ul>

How could I listen the event when automatic merge updated and symbolic refs been updated?

Does creating AutomaticMergeEventListener is right way?

When automatic merge updates?

I just need to operate with actual PR`s symbolic refs.

[cofarrell]

Hi Dana,

The "maybe" is because it depends on whether the pull request is open. Previously it was created for all pull requests, but that was polluting the ref space, which in turn would make clones/fetches slower as a repository had more pull requests. Are you concerned about declined/merged PRs?

I'm sorry but as we've said previously we you are really relying on internal details of Stash. These may change at any point. Honestly, if it were me, I would do your own merging and create your own refs that you can rely on, as long as you are careful about the performance of Stash.

It's very unlikely we will create an even you can listen for.

Charles

[Alexey_Efimov]

Hi Charles,

We already invistigated this. The Automerge Event is not from this area.

We need to run Teamcity builds from Stash. To solve this, we call getEffectiveDiff and after this send REST call to Teamcity. If we did not call getEffectiveDiff, then Teamcity can start build on previous /from link, cos Stash not invalidated it yet.

So, we try to find way to monitoring, then /from reference is changed.

[cofarrell]

Hi Alexey,

Oh, I think I understand what Dana meant about AutomaticMergeEventListener now.

It's an unfortunate naming clash between the automerge that happens to pull requests when they are rescoped and automatic merges that happens for release branches. The events are thrown from branch-utils for the automatic release merges, as I guess you know.

You're looking for some sort of RefChangedEvent?

Charles

[Alexey_Efimov]

Yes, really RefChangedEvent will be nice. But we can't find anything in API about this.