chore: Prevent creating a release which includes uncommitted changes

[TomAFrench]

I noticed that the 0.1.0 version of nargo doesn't correspond to the commit from which it was built (running nargo --version returns a git commit suffixed with modified). This PR adds a quick check so that if the output of nargo --version includes this suffix then the release is halted.

I think that the issue with 0.1.0 is due to this release being made prior to build-nargo existing and so this check shouldn't trigger here however I think we should explicitly check to ensure that the builds we publish correspond to the commits we're saying they're from.

[phated]

I rebuilt 0.1.0 when we tagged it before release-please. I think something else might be going on?

[TomAFrench]

I'm not sure on the circumstances around the 0.1.0 release but if you download it and run nargo --version then we can see that it's not running the code it should.

[phated]

But why? if we don't know why this happens, then how is a spurious error going to help us? 🤔 It could be a cargo lock thing? It could be something else? Do we need to build in cargo frozen mode?

[phated]

The action is pretty simple, in that it just checks out the tag and runs one command. We should be able to track it down (and then hopefully fix the 0.1.0 binaries).

[TomAFrench]

Looks like it's the hack which was removed in #3. We were injecting in a new dependency which causes this issue.

[phated]

Looks like it's the hack which was removed in #3. We were injecting in a new dependency which causes this issue.

🎉 Sweet, that makes sense!

[TomAFrench]

That said, on second thoughts this check should likely be moved to be one of the uvu tests rather than being run in GH actions directly.

[TomAFrench]

closing in favour of #8