Publish released version binaries

[ivanvc]

At @etcd-io, we're using marker as linter. We're moving our infrastructure to an environment that doesn't have Rust/Cargo available. We would like to be able to download a binary without having to install Rust.

With this PR, I introduce a GitHub action that gets triggered when a tag is pushed. It builds the binaries and publishes them as a GitHub release. You can see a fictional release at my fork: https://github.com/ivanvc/marker/releases/tag/v0.9.12

I also vendorized OpenSSL, as it was a challenge to get it working in a GitHub runner.

[crawford]

Very cool! Thank you for your effort on this. I need some time to review this more thoroughly and test some stuff out. What's the timeline for migrating the infrastructure?

Off the bat, I have a couple questions:

• Do you need Windows support? I don't really have the resources or the desire to test on Windows, so I'm not keen to publish binaries for that platform.
• Do you mind if I push additional changes to your branch (to speed up iteration)? I want to add some level of build attestation and pin cross-rs to a specific release.
• Do you make use of the online link verification in CI or do you use --skip-http? I'm wondering if we can just build with the network feature disabled and drop the vendored OpenSSL.

[ivanvc]

Hey @crawford, thanks for looking into this. Answering inline:

Very cool! Thank you for your effort on this. I need some time to review this more thoroughly and test some stuff out. What's the timeline for migrating the infrastructure?

We've already migrated. Markdown linting is a low priority for the repository. So, there is no rush, but ideally, we would like to re-enable it in the short term.

Off the bat, I have a couple questions:

* Do you need Windows support? I don't really have the resources or the desire to test on Windows, so I'm not keen to publish binaries for that platform.

No, we don't! As cited in https://github.com/crawford/marker/pull/32/files#diff-e426ed45842837026e10e66af23d9c7077e89eacbe6958ce7cb991130ad05adaR1, I based the YAML on cardinal-rs'. Fully transparency, I'm not familiar with Rust; I'm a Go developer.

* Do you mind if I push additional changes to your branch (to speed up iteration)? I want to add some level of build attestation and pin cross-rs to a specific release.

Not at all. Feel free to modify/adapt this to your needs. I checked "allow edits by maintainers," so you should be able to push it into my branch (again, full transparency: I'm not familiar with Rust:sweat_smile:).

* Do you make use of the online link verification in CI or do you use `--skip-http`? I'm wondering if we can just build with the network feature disabled and drop the vendored OpenSSL.

We do run it with --skip-http, refer to:

https://github.com/etcd-io/etcd/blob/fbda59186605b1c1a8fc06c6e65a33dcb98e2fbd/scripts/test.sh#L361-L366

Thanks again for looking into this Alex.

[ivanvc]

Hi @crawford, have you been able to take a look at this? Feel free to let me know if there's anything else I can help with to get this forward.

[crawford]

@ivanvc sorry, this fell off the end of my mental queue (and was apparently buried in my inbox/todo list). I'll take a look this afternoon.

[crawford]

@ivanvc how does this look? I dropped Windows entirely and Linux on ARM64 and i686. Once this is merged, I'll go ahead and tag a release.

[ivanvc]

Thanks, this looks great, @crawford. I ran it in my fork, and it worked: https://github.com/ivanvc/marker/releases/tag/v0.9.14 🎉

I also verified the generated Linux binary, which works as expected. But I don't have a way to test the macOS ones.

[crawford]

@ivanvc awesome, thanks for helping me verify that. I was able to test the MacOS build for AMD64, which worked. I'm going to just assume that ARM64 works as well, since I have no way to test that.

After sleeping on it, I decided to make a small modification to the release workflow. Instead of emitting a binary called marker-{target}, it emits a tarball named marker-{version}-(target}.tar.gz with marker inside. This way, no matter the architecture, the (unpacked) executable is the same. Plus, the executable access permission is preserved.

Thanks for your patience on this.

[crawford]

And here is the release: https://github.com/crawford/marker/releases/tag/v0.10.0