Add cargo-tarpaulin support

[thomcc]

Given that actions-rs/tarpaulin is currently broken, it'd be nice for folks to have a migration path.

This will conflict with #41 -- I wasn't sure if you preferred I do this on top of that branch, or what, but this is cleaner in case you have feedback/changes you'd like me to make to that one. I'll rebase after that merges, or you can push the fix to my branch if I'm not around (I don't care much).

Note: cargo-tarpaulin only provides binaries for x86_64-unknown-linux-gnu, and the tarballs have fairly idiosyncratic names. It's plausible that will have to change if cargo-tarpaulin ever provides other binaries, but at the moment it does not, so who knows.

[NobodyXu]

Note: cargo-tarpaulin only provides binaries for x86_64-unknown-linux-gnu, and the tarballs have fairly idiosyncratic names. It's plausible that will have to change if cargo-tarpaulin ever provides other binaries, but at the moment it does not, so who knows.

P.S. cargo-quickinstall provides builds for x86_64-pc-windows-msvc and x86_64-apple-darwin.

[thomcc]

I removed it from the container CI. It fails on most of them due to

• needing openssl 1.1 (which seems to be an accident, since it also tries to vendor it...)
• requiring a more recent glibc (seems to work on >=2.31)
• not providing a linux-musl build (unsure why, given https://github.com/xd009642/tarpaulin/blob/86250b7bbc12d70afdfd35214408e461e1b05e0c/.github/workflows/release.yml#L22-L23, although I'm unsure if it's used).

I could also duplicate the debian:11-slim job if you'd like.

[thomcc]

Note: cargo-tarpaulin only provides binaries for x86_64-unknown-linux-gnu, and the tarballs have fairly idiosyncratic names. It's plausible that will have to change if cargo-tarpaulin ever provides other binaries, but at the moment it does not, so who knows.

P.S. cargo-quickinstall provides builds for x86_64-pc-windows-msvc and x86_64-apple-darwin.

Oh, hm. I'm noticing now that the GH releases for tarpaulin are behind a few versions too -- only covering up to 0.22.0 (latest is 0.23.1)... A bit unsure what to do here.

[NobodyXu]

Note: cargo-tarpaulin only provides binaries for x86_64-unknown-linux-gnu, and the tarballs have fairly idiosyncratic names. It's plausible that will have to change if cargo-tarpaulin ever provides other binaries, but at the moment it does not, so who knows.

P.S. cargo-quickinstall provides builds for x86_64-pc-windows-msvc and x86_64-apple-darwin.

Oh, hm. I'm noticing now that the GH releases for tarpaulin are behind a few versions too -- only covering up to 0.22.0 (latest is 0.23.1)... A bit unsure what to do here.

You could use quickinstall builds instead, which provides the latest v0.23.1

The name is also very predictable and I think it can run on old glibc.

Though I recommend use them through cargo-binstall, which will also report stats back to quickinstall.

[thomcc]

You could use quickinstall builds instead, which provides the latest v0.23.1

Hm, I'm unsure how to set that up in the manifest templates, if that's what you're suggesting.

[NobodyXu]

You could use quickinstall builds instead, which provides the latest v0.23.1

Hm, I'm unsure how to set that up in the manifest templates, if that's what you're suggesting.

quickinstall url for cargo-tarpaulin goes like this:

https://github.com/cargo-bins/cargo-quickinstall/releases/download/cargo-tarpaulin-{version}-{target}/cargo-tarpaulin-{version}-{target}.tar.gz

[thomcc]

https://github.com/cargo-bins/cargo-quickinstall/releases/download/cargo-tarpaulin-{version}-{target}/cargo-tarpaulin-{version}-{target}.tar.gz

I see. I think I need to extend tools/codegen to support this.

[thomcc]

Ah, wait, maybe I'm being thick -- I see now that install-action already will automatically use cargo-binstall. I didn't realize this -- was your point that I should probably just drop this PR and go that route?

(I don't love that -- I think direct support would be better, but also I don't know how much more time I feel like spending on this...)

[NobodyXu]

I see. I think I need to extend tools/codegen to support this.

Nope, this is just the same as you would do otherwise.
It's just a github release artifact.

Ah, wait, maybe I'm being thick -- I see now that install-action already will automatically use cargo-binstall. I didn't realize this -- was your point that I should probably just drop this PR and go that route?

That's also feasible since cargo-binstall can already install cargo-tarpaulin with no problem.

[NobodyXu]

(I don't love that -- I think direct support would be better, but also I don't know how much more time I feel like spending on this...)

I would say that if you don't have enough time, simply drop this and fallback to cargo-binstall.

IMHO cargo-binstall is quite good at its job and now cargo-quickinstall is also managed by us cargo-bins.

[thomcc]

I'm just going to go with grcov for now, I think.

[taiki-e]

I think the best way here would be to help them fix their release workflow and add linux-musl/macos/windows support (xd009642/tarpaulin#1130). (If they are fine with using my upload-rust-binary-action action (used by cargo-llvm-cov, tokio-console, nextest, etc.) then I think it should be easy to do.)

---

I see. I think I need to extend tools/codegen to support this.

Nope, this is just the same as you would do otherwise. It's just a github release artifact.

I think this need to at least add support for tag suffixes to codegen. Currently only tag prefixes are supported.

[NobodyXu]

I think this need to at least add support for tag suffixes to codegen. Currently only tag prefixes are supported.

Oops you are right, I didn't know this.

[thomcc]

I think this need to at least add support for tag suffixes to codegen. Currently only tag prefixes are supported.

Yeah, and solving this is kind of annoying because the suffix isn't static the way the prefixes are -- it's the dynamic target name. Solving this required more thought than I had time for, so I punted.

I think the best way here would be to help them fix their release workflow and add linux-musl/macos/windows support (xd009642/tarpaulin#1130).

I happened to chat a bit with @xd009642 on Discord while writing this PR and I think they're open to this.

[orhun]

Now that cargo-tarpaulin has a proper release workflow, can we reconsider this?

[taiki-e]

Yeah, I would accept a PR to support cargo-tarpaulin.

[taiki-e]

Added in 2.4.0 (#65).