Proposal: Enhance the experience of syncing stable branches and tags
Context
When a release is published, the respective stable branch and tag are synced to the canonical, security, and dev repositories. This is not an ideal design for the following reasons:
- The sync is not necessary for patch or monthly releases, stable branches, and tags are protected and therefore automatically mirrored to Security and Dev.
- On security releases:
- Syncing branches and tags is where the
publish
job takes most of the time (example). Thepublish
job takes around 18 minutes, which makes ~54 minutes of release managers waiting for the three publish jobs to complete. - Syncing branches and tags is done before publishing the packages, the former is a time-sensitive operation that is delayed until stable branches and tags are synced.
- Syncing branches and tags is where the
Proposal: Enhance the experience of syncing stable branches and tags
The experience of syncing stable branches and tags when publishing could be improved by:
- Skip the sync if it is a patch or a monthly release
- On security releases, move the syncing process to a dedicated job outside the
publish
job. Release managers will continue to publish the packages as usual, while stable branches and tags can be synced at a different step/job - Verify if the tag or the stable branch is up to date before syncing. Sometimes syncing a stable branch fails for one project but it doesn't for the others, in this case, the job is retried which attempts to update all the projects again.
Pros
- Removes non-required steps from the release process
- Reduces the time release managers have to wait when executing the publish jobs.
- Speeds the publishing process of release packages.
Cons
- On security releases, this assumes the packages don't require the tags to be available on canonical, it might not be accurate and needs to be investigated.