Add assertPrerelease option to stop releases outside of release.yml

[iwahbe]

We accidentally releases one of our providers
artifactory by merging into main (without running the release workflow). This left the provider in an invalid state, since main did not publish a release provider binary, but it did publish a release SDK.

The solution is to prevent publishing release SDKs in any workflow besides release.yml.

As a follow up, I will add assertPrerelease: true to all workflows except release.yml.

[guineveresaenger]

I'd love there to be a link to this tool's README but am honestly not sure how to do it succinctly.

[danielrbradley]

I think this is a sensible addition, but it wouldn't have stopped the publishing of the non-prerelease nuget package. You can see this by looking at the usages of inputs.version - it's only passed down into the Java publishing workflow - it's not used by the dotnet, python or node publishing actions.

The version passed into the publish action for artifactory was a correct pre-release version, but that version isn't used for the dotnet nuget release - the version number is already in the .nupkg file. This was caused by the makefile overriding the PROVIDER_VERSION variable that was set by CI - and building an asset with the major version number in.

A complete fix here would also require passing version down to each language-specific action (ideally as inputs not env) and in each verify that the package they're about to publish matches the version passed in.

[iwahbe]

I think this is a sensible addition, but it wouldn't have stopped the publishing of the non-prerelease nuget package. You can see this by looking at the usages of inputs.version - it's only passed down into the Java publishing workflow - it's not used by the dotnet, python or node publishing actions.

The version passed into the publish action for artifactory was a correct pre-release version, but that version isn't used for the dotnet nuget release - the version number is already in the .nupkg file. This was caused by the makefile overriding the PROVIDER_VERSION variable that was set by CI - and building an asset with the major version number in.

A complete fix here would also require passing version down to each language-specific action (ideally as inputs not env) and in each verify that the package they're about to publish matches the version passed in.

Thank's for pointing that out! Good catch.

[iwahbe]

A complete fix here would also require passing version down to each language-specific action (ideally as inputs not env) and in each verify that the package they're about to publish matches the version passed in.

It's not trivial to do that, especially for python and dotnet. I have added validation to nodejs (which published first), asserting that the version to be published matches ${{ inputs.version }}. This doesn't ensure safety, but it makes it much more likely, since if all SDKs are built with the same version, this will catch the problem.

[danielrbradley]

Yup, this will suffice for now as it would have prevented the previous failure.

As a side-note, given this is an action rather than a re-usable workflow, perhaps we shouldn't be installing the tools ourselves, but assume the caller should have set up the tools themselves (as we do now using the shared workflow) to avoid fragmentation (e.g. configuring cache settings etc) and modifying the caller's environment. Alternatively, we could model this as a workflow so we're creating our own clean environment.

[VenelinMartinov]

lgtm

[iwahbe]

As a side-note, given this is an action rather than a re-usable workflow, perhaps we shouldn't be installing the tools ourselves, but assume the caller should have set up the tools themselves (as we do now using the shared workflow) to avoid fragmentation (e.g. configuring cache settings etc) and modifying the caller's environment. Alternatively, we could model this as a workflow so we're creating our own clean environment.

I think we should model this as a workflow for full self-containment, but that is a separate PR.