When we made this, I argued for not reading .release scripts automatically (as ReleaseTools had done); my argument was that one can just do that in a release workflow file if desired, and it's better to keep this action simple.
After having worked with this on a couple dozen packages, I have come to regret this, and now think we should add this after all: we should execute such a script if found, and also prevent it from getting into the release archives.
Reason 1: it makes it harder to test this; one either has to do a dry run release online; or copy&paste from a workflow YAML. In contrast, a script can just be executed manually... Of course one can deal with that by just having a .release script that one then executes in the release workflow. Except that then, one also has to be careful to remove it, with many packages forget, e.g. I found these in GAP's pkg directory:
- pkg/curlinterface/.release
- pkg/factint/.release
- pkg/primgrp/.release
- pkg/sglppow/.release
- pkg/simpcomp/.release
Reason 2: several recent changes to our actions have had the aim to minimize the need for deviations from the "default" script. As a result 142 out of 150 packages in gap-packages with a .github/workflows/docs.yml have the same. For release.yml it is currently 143 out of 166.
One problem with doing that this would break if we just aded it to v1, as some release workflows indeed already execute .release scripts -- if we execute them a second time, that may cause all kinds of problems.
So either we'd have to put this into a v2 of release-pkg -- but then we'd have to update ~170 repos or so.
Or, for less churn, we could implement it, but give the script a different name that nobody currently uses, e.g. .release-pkg
Anyway... I am still not completely decided on this; input from others whether this is a good or bad idea welcome!
When we made this, I argued for not reading
.releasescripts automatically (as ReleaseTools had done); my argument was that one can just do that in a release workflow file if desired, and it's better to keep this action simple.After having worked with this on a couple dozen packages, I have come to regret this, and now think we should add this after all: we should execute such a script if found, and also prevent it from getting into the release archives.
Reason 1: it makes it harder to test this; one either has to do a dry run release online; or copy&paste from a workflow YAML. In contrast, a script can just be executed manually... Of course one can deal with that by just having a
.releasescript that one then executes in the release workflow. Except that then, one also has to be careful to remove it, with many packages forget, e.g. I found these in GAP'spkgdirectory:Reason 2: several recent changes to our actions have had the aim to minimize the need for deviations from the "default" script. As a result 142 out of 150 packages in
gap-packageswith a.github/workflows/docs.ymlhave the same. Forrelease.ymlit is currently 143 out of 166.One problem with doing that this would break if we just aded it to v1, as some release workflows indeed already execute
.releasescripts -- if we execute them a second time, that may cause all kinds of problems.So either we'd have to put this into a v2 of
release-pkg-- but then we'd have to update ~170 repos or so.Or, for less churn, we could implement it, but give the script a different name that nobody currently uses, e.g.
.release-pkgAnyway... I am still not completely decided on this; input from others whether this is a good or bad idea welcome!