Rubygems release on tag push #1554
Conversation
It is known that there is a defect in the release process when triggered in a certain context, evident from mikel#1489. This results in a large degree of frustration, as well as the inability of anyone other than the individual who triggered the release to debug the source of the problem. Here we automate the release process as a Github Action which is triggered by a push of a tag which begins with `v`, such as `v2.8.1`. In order for this to work correctly, it is necessary to set the secret `rubygems_api_key` on the Github repo, which is something only @mikel can do, but once he does that a release can be cut by anyone with the ability to push tags to this repo, and the release process is executed in a clean context like that in which tests are run, making it available to debugging efforts by the broader community.
|
Seems somewhat risky to me. It would be easy to create a release tag in error. Is there a way to generate a staging release that can be used for testing and then promoted to a formal release? |
|
@sebbASF This works well for my organisation on several projects, and we've never had a problem with mistakenly creating a tag; we use the Github Releases UI to create tags after merging a PR which bumps the gemspec version. I get that in theory a mistaken push could happen, but in my experience it's so rare (I've never seen it in hundreds of releases across dozens of projects) that it's not worth worrying about. One option would be to have this triggered from the Github UI explicitly instead, but this is then a two-step process.
That does not address the concern which arises out of #1489 , I'm not sure what the benefit would be. |
I was thinking that a staging release would be used in a test suite which is set up to run tests as a user id other than the installer. This would have detected the permission error. If the same artifact can be promoted to a formal release, then it would already have been tested. Obviously if the release has to be regenerated, that assurance would be lost. |
Indeed, but that's far more specific than I was attempting to resolve here. I'm not trying to build any kind of regression testing for the permissions issue, because it's very specific to @mikel 's machine/routine, I'm just trying to generally decouple the release process from his personal situation and put it somewhere repeatable. As for detecting the problem in #1489 ahead of time, it was detected several RC releases in advance and was not considered in the final release, so I don't think any more automation of the detection of the issue would have helped. |
I agree it would not have prevented the issue, but it would have flagged it up immediately on release |
|
@eval Interested in moving forward with this or should I close it? |
It is known that there is a defect in the release process when triggered in a certain context, evident from #1489. This results in a large degree of frustration, as well as the inability of anyone other than the individual who triggered the release to debug the source of the problem.
Here we automate the release process as a Github Action which is triggered by a push of a tag which begins with
v, such asv2.8.1. In order for this to work correctly, it is necessary to set the secretrubygems_api_keyon the Github repo, which is something only @mikel can do, but once he does that a release can be cut by anyone with the ability to push tags to this repo, and the release process is executed in a clean context like that in which tests are run, making it available to debugging efforts by the broader community.