Fix release-signing-artifacts behavior and docs#103
Conversation
Signed-off-by: William Woodruff <[email protected]>
Signed-off-by: William Woodruff <[email protected]>
Signed-off-by: William Woodruff <[email protected]>
|
Looks good to me. |
jku
left a comment
There was a problem hiding this comment.
This looks good to me when I take for granted that the action expects to be run on a workflow triggered by "release" event to be able to do this (it's a bit weird but I can see why -- GitHubs release tarball baking happens in a black box)
|
|
||
| The `release-signing-artifacts` setting controls whether or not `sigstore-python` | ||
| uploads signing artifacts to the release publishing event that triggered this run. | ||
| This setting has no effect on non-`release` events. |
There was a problem hiding this comment.
I also did not realise the intended usage was to use the "release" event so this is useful (I've always made my release pipelines triggered from release git tags).
There was a problem hiding this comment.
Same here, which is why I tripped over it.
There was a problem hiding this comment.
Yep, this was entirely an oversight on our side -- the actual release uploading step only runs when the event name matches; we just missed the corresponding check on this side 🙂
|
Thanks for fixing so quickly folks, this is what makes open source so great 🥇 |
This has two parts:
release-signing-artifactsif theGITHUB_EVENT_NAMEis notrelease, since it can only work in the context of releases and their associated artifacts.release-signing-artifactsnow makes this clear.CC @stevenh for review as well, as the original reporter 🙂
Closes #99.