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.

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.

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.

@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.

@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.

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.

@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.

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