Release Process Improvements

[arielvalentin]

Description

Releasing gems is a difficult process that is error prone. I have had several instances where I have had to manually update/repair issues with the releases due to transitive dependencies and local Gemfile references.

I have also had occasions where I have missed rolling out gem dependencies in the proper order. The most recent being missing a release of base changes that were also included as part of changes to support the new graphql API:

#453

The local gem references also cause friction during a release because it will require an update to all and possibly the rails gems due to transitive dependencies.

I currently have to make additional changes on a release branch in order for the gem dependencies to resolve correctly during a build:

bea8756

This ends up triggering an unintended gem push for the gem I had to update manually on the release branch, even though It is not intentional:

#506

Lastly, Actions Bots creating PRs from release requests do not trigger CI matrix builds. This requires the person performing the release to manually force CI by submitting empty commits or corrections to the change log.

What am I asking for?

I would like for the release process to be aware of gem dependencies and all of the changes that are required to ensure a release can go out safely and not have to keep track of what order gems must be released in.

In addition to that I want to know what gems have pending changes that have not yet been released or automatically generate release requests on my behalf.

I would also like to be able to release all versions of sub-packages like instrumentation without having to enumerate them all when opening a release request.

Lastly, I want for Release Request PRs to trigger CI matrix builds by default

[arielvalentin]

@dazuma pointed out to me that toys will only release gems that have changed if you do not specify them, however the actions prompt is misleading:

That lead me to believe I had to explicitly specify what gems I wanted to release.

[dazuma]

@arielvalentin

I'll update the text on the github action parameter.

I suspect the reason release request PRs don't trigger CI matrix builds is the github actions rule that one action cannot trigger another. Or at least, I believe the way it's implemented is that the github-actions bot account cannot trigger another github action. It's possible we might be able to address this by creating a separate bot account specifically to run releases. I'll look into this possibility.

Now regarding the dependency issue, let me make sure I understand the scenario…

Gem A depends on Gem B (i.e. a base gem). We make changes to both A and B, and the changes to A depend on the changes to B. Thus, we want the tool to ensure that if we release A then we also release B. (And maybe we might also want it to update As gemspec appropriately to depend on the new version of B?)

Am I describing the issue correctly?

If so, it seems like a difficult problem, to analyze changes made to A and determine whether they are dependent on changes made to B.

We could approach it conservatively, and say that if any change has been made to B, and we know A depends on B, then we ensure B gets released if A is released (regardless of whether the changes to A are actually dependent on changes to B.) That could result in B being released more often than we strictly need, but maybe that's fine: might as well release B if any applicable changes are present. Does this sound reasonable? I think it would be possible to do.

[github-actions]

👋 This issue has been marked as stale because it has been open with no activity. You can: comment on the issue or remove the stale label to hold stale off for a while, add the keep label to hold stale off permanently, or do nothing. If you do nothing this issue will be closed eventually by the stale bot.