Add docs warning about merging too quickly about auto

[hipstersmoothie]

Possible solution to this discussed with @adierkens:

Set a status on all open PRs to fail while release is in progress. This way a user cannot merge until this status turns green.

Kinda weird but would fix the problem

[zephraph]

That's certainly one solution. I'm trying to handle this at the CI level by queuing master builds. Unfortunately Circle doesn't provide a native mechanism for this, but @eddiewebb created an orb to handle it.

You can checkout reaction to see our setup. I'm not 100% certain that it solves the problem (especially if instead of checking out master the steps are checking out a hash) but I hope it gets us close.

[adierkens]

If you queue the master build you run into the issue where you're first CI build of master makes commits on top of the stuff that's already been merged (to bump versions) -- or could hit merge conflicts in the release.

Not sure if there's a clean way of doing it

[hipstersmoothie]

Also:

1. Merge PR 1 with patch label
2. Merge PR 2 with minor label
3. CI runs and calculates a minor bump and includes both PRs
4. CI runs again and publishes a patch with no changes

Should be:

1. Merge PR 1 with patch label
2. Merge PR 2 with minor label
3. CI runs and calculates a patch bump and includes only PR 1
4. CI runs and calculates a minor bump and includes only PR 2

[zephraph]

Yeah, that's certainly a concern... You'd need a way to update the hash that CI build is pointing to. That or have a similar gated mechanism to the queuing that kills incoming builds and have the end of the release process trigger another CI build if there are pending things to be released.

Granted, that's not a general solution. It implies a lot of specific implementation around CI.

[aleclarson]

Could auto-release publish multiple versions in a single CI build?

[hipstersmoothie]

Maybe, the problem is a lot of this behavior is CI dependent and auto doesn't interact with the CI it just runs on it.

[aleclarson]

I was thinking in the context of Travis CI specifically, where pushing interrupts the current build. In that case, auto-release should be able to detect that the patch PR was merged before the minor PR and appropriately perform two releases as expected. AFAICT, this behavior wouldn't conflict with other CI services that don't interrupt the current build on push.

[hipstersmoothie]

In that case this should already work for travis:

1. minor merged, starts CI run
2. patch merged, travis interrupts CI run before the minor gets tagged or released to GitHub
3. auto version finds the latest release to be the one before minor was merged
4. a minor version is released with both the minor and patch

The case where you might run into problems is where the second PR is merged between the publish hook and auto release. But in this case we might already have code that can handle that.

[aleclarson]

If you re-read my comment, you'll see I said "patch before minor" (not the opposite).

[hipstersmoothie]

The case where "minor before patch" is more important though. if the minor is the first PR we need to respect that label more.

But re-reading what you want is on the second CI run detect the interrupted run and perform two separate shipits for each release, regardless of release type. Am i correct?

[aleclarson]

The case where "minor before patch" is more important though. if the minor is the first PR we need to respect that label more.

What unwanted effect would you be avoiding in that scenario?

But re-reading what you want is on the second CI run detect the interrupted run and perform two separate shipits for each release, regardless of release type. Am i correct?

Actually, you would be detecting the patch PR being not yet released. The cause (eg: interrupted CI build) is irrelevant to auto-release, I think. You could still merge two PRs of the same release type (eg: minor) into the same version if you detect that neither is released yet.

[adierkens]

🚀 Issue was released in v7.15.1 🚀