damccorm commented on PR #26793: URL: https://github.com/apache/beam/pull/26793#issuecomment-1557645467
> 0. Assuming master is on version 2.X.0-SNAPSHOT > 1. Select a commit Z from which to branch > 2. Create the branch release-2.X.0 at commit Z > 3. Push a commit to move master to 2.(X+1).0-SNAPSHOT > Each of 1, 2, and 3 are logically independent. There is no reason for a failure in 3 to even cause us to consider rerunning 2. 1 and 2 are definitely not logically independent, 2 depends on 1 to define the commit its using. 2 and 3 are ~mostly~ independent, though 3 definitely needs to happen after 2 (in commit history), so there is still an interdependence there. > To clarify one thing: the commit chosen by step 2 has to still be on 2.X.0-SNAPSHOT. I'm not suggesting it can be executed against a commit after step 3 has advanced the version. Oof, I just noticed this actually is a bug in the workflow right now, we do this out of order. It doesn't matter in the success case because GHA uses the same sha for both, but this would be a problem in the failure case (probably because the original script had them bundled into one step, and the workflow author didn't realize there was an important distinction since they'd never actually run a release). I adjusted to fix this. > 2. Locate the/a last commit with 2.X.0-SNAPSHOT > 3. Create the branch release-2.X.0 at said commit I really don't like this. This logic would be as complex than the entire rest of the script, and it only helps in the failure case (so we're opening ourselves up to just as many failures). Parsing git history for certain contents is not a good pattern for us to follow in our infra scripts. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
