Open slimsag opened 5 years ago
Haven't figured that out, so I removed the env var for now.
Potential solution: only check on PRs, not on release branches or master.
See my commit ebe7a3ab94814a548b84a25b71054f7eb2a61ae3 to address this. The env var now takes a comma-separated list of acceptable commits.
What's the intended workflow? Upon cutting a release branch, add to MUST_INCLUDE_COMMIT
the hash of the first commit on the release branch that is not in master? Something like the last commit listed in git log 3.7 --not master
?
It depends on whether or not MUST_INCLUDE_COMMIT
commit (on master) should be cherry-picked to the release branch or not. If it's not cherry-picked, then ensure the release branch has at least one commit not on master and then add the release branch HEAD commit to MUST_INCLUDE_COMMIT
. If it is cherry-picked, then add the new HEAD commit (from cherry-picking) to MUST_INCLUDE_COMMIT
.
We chatted about this at the distribution sync. Conclusion: We should change MUST_INCLUDE_COMMIT
to only take effect in non-release branches (e.g. 3.7
branch or v3.7.0
tag)
I could not cut a 3.7 patch release because of this behavior. We will experience the same thing trying to release patches in 3.8, 3.9, etc.
How is this behavior supposed to work for patch releases? @beyang @chrismwendt