Update release workflow

[PsypherPunk]

Apologies if this is excessive but following #427, there are a few things I noticed:

1. Cargo.toml now supports strip which I think should replace the explicit strip steps in the release workflow, unless there's any other reason they're not quite identical…?
2. the trigger for the release workflow includes a tag with a v prefix. However, no existing tags/releases have that prefix; I've removed it and updated the workflow accordingly.
   • the docker.yml has the same trigger—if the above holds true, should that be updated to match?
3. as kinda touched upon in feat(build): add GitHub Action to make release #427, I've made the OS/build checks in each step more generic (i.e. matching linux, not x86_64-linux) so if future architectures are added, the workflow should accommodate them.

Let me know if I've misread anything or any of the above isn't required/desired.

[bee-san]

@CMNatic :

the docker.yml has the same trigger—if the above holds true, should that be updated to match?

👆🏻 I think this is true, but @CMNatic knows so much about our Docker setup so I'll defer :D

And why can't it log into Docker via the CI? It's in the actions secrets :(

it does not see those secrets?

And thanks @PsypherPunk !!!

[bee-san]

@PsypherPunk waiting on @CMNatic to have a lil look

then i'll merge this and try a release 🥳

[PsypherPunk]

@bee-san, come to think of it, I don't think builds triggered by pull-requests get access to secrets (to avoid external parties raising PRs to steal them, presumably): https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow

[CMNatic]

Hey 👋🏻

the docker.yml has the same trigger—if the above holds true, should that be updated to match?

Ahh good catch @PsypherPunk. Yes, I think this should also be updated to match :)

I don't think builds triggered by pull-requests get access to secrets

This is my understanding as well. I've double-checked the repo secrets for the dockerhub and they are correct. I think the PR will need to be merged for the runner to run. It's not super ideal, but it does make sense. A new commit will cause a publish to the latest tag which is documented as bleeding-edge. The runner isn't doing any sort of code review or checking if build works, it's just publishing an image:)

If it doesn't, I have a PR ready that uses a newer version the Docker login runner, which uses a access token instead that we can test @bee-san

[bee-san]

the docker.yml has the same trigger—if the above holds true, should that be updated to match?

Mind doing this in another PR? :)