Executable build workflow

[ksmoore17]

CD workflow for building Rust binaries and publishing to crates.io as adapted from here and here.

See my test release run here (fails because no crates.io publish token in the repo secrets)

Rust targets with executables built include:

• x86_64-apple-darwin
• x86_64-unknown-linux-gnu
• x86_64-pc-windows-msvc
• aarch64-unknown-linux-gnu
• i686-unknown-linux-gnu

It's easy to add different architectures and os versions in the matrix, but I believe this covers all of what github has to offer currently.

I'd suggest to test an alpha release or something, and if anything goes wrong with the cargo publish, add back the "--allow-dirty" flag as seen at the end of both of the examples you shared. I removed the flag because I felt it was extraneous (how is the ref gonna be dirty if we're working off a commit checked into github). There also needs to be a repository secret called CARGO_API_KEY from crates.io.

Resolves #12

[okaneco]

Thanks for all of this, I saw the releases on your branch's tag and it looks great.

Two small changes before merging:

1. Could you squash your commits to 1 commit?
2. I'd prefer to manually publish to crates.io because I may do some testing with tags and don't necessarily want to publish each version to crates.io. Could you remove the publish-cargo job on lines 107-122 and keep the newline on 106?

I'm excited to merge this and push a new tag 👍

[ksmoore17]

Done. The workflow triggers on a x.x.x tag. I don't know if that's what you wanted; let me know and I'll revise/resquash/repush. Seems to me like Github makes the newline disappear (you can see it missing in the ci workflow too), but it's there when I pull back down.

[okaneco]

The workflow triggers on a x.x.x tag.

That seemed like what I'd want for now over the regex pattern. I realized earlier today that the strict regex pattern in one of the example workflows allows for not publishing a release for "preview/beta" tags, so that's one benefit to it over the wildcard pattern if that behavior is desired.

If you look at the other workflow, you'll see there's a workflow_dispatch that's necessary for running an action manually. This is useful for (re-)running CI but I don't think that gets us much on pre-existing tags: I don't think I can point to a release tag telling the action to make binaries for that retroactively and publish them.

No worries about the newline, everything looks good for a merge now. 🎉

I'll be bumping the rand dependency to 0.8 later and fixing a few new clippy lints after this is merged. I'll publish a 0.1.2-binary tag so this is published as a binary before that.