CI: Use new cargo rmbt tool

[tcharding]

Use Nicks mad new tool to run CI. To do this I copied what is in rust-psbt, guessed at what bench should be, and used the latest commit hash from rust-bitcoin-maintainer-tools repo.

[tcharding]

Probably should have an ack from @nyonson before merge, I hacked this pretty quickly without thinking super hard.

[tcharding]

@nyonson, your CI work is shit-hot mate. Well done. Want to do it in rust-bitcoin or want me to? I have already used cargo rbmt locally to test a rust-bitocin PR!

[apoelstra]

In 1231487:

The commit description has some cruft about error return sizes which isn't applicable to this commit.

[apoelstra]

In f58468d:

This bumps the MSRV to 1.74, which I'd rather not do as long as we depend on rust-bitcoin 0.32. But also, you say 1.64 somewhere (typo).

[apoelstra]

On ed9195b successfully ran local tests

[apoelstra]

The MSRV will also be an issue for rust-elements.

We can attempt to back the MSRV for rbmt up, or we can figure out how we can cargo install with a newer compiler than we use to compile the actual project code.

[nyonson]

@apoelstra as it is right now in ed9195b, it actually installs rbmt with the stable toolchain and then installs the asked for toolchain (maybe in the future we could use this "artifact dependencies" thing cargo is working on so this dance is never required). So I don't think the MSRV bump is required here for rbmt. FWIW rmbt does work with its stated 1.74 with your version fixes so I was able to simplify this for workspaces with MSRV of 1.74: https://github.com/tcharding/rust-psbt/pull/44/files

[apoelstra]

Awesome. So let's try doing this one without the MSRV bump.

[tcharding]

I'm hazy AF right now but lets see if CI likes my changes. FTR I dropped the MSRV patch and copied .github/actions/prepare/action.yml from the rust-psbt linked PR (now merged).

[tcharding]

as it is right now in ed9195b, it actually installs rbmt with the stable toolchain and then installs the asked for toolchain

I'm confused,

  run: cargo install --git https://github.com/rust-bitcoin/rust-bitcoin-maintainer-tools.git --rev "$(cat rbmt-version)" cargo-rbmt --locked

Only one toolchain gets installed by actian.yml, right? So rmbt gets installed using that toolchain, and here in msrv job that is too low.

Don't we need to pass a list of toolchains to install then use +stable or something in the rmbt install command?

[apoelstra]

Only one toolchain gets installed by actian.yml, right? So rmbt gets installed using that toolchain, and here in msrv job that is too low.

Yeah, that was also my understanding. Can you clarify @nyonson how you were intending us to invoke this?

[nyonson]

Only one toolchain gets installed by actian.yml, right? So rmbt gets installed using that toolchain, and here in msrv job that is too low.

Yeah, that was also my understanding. Can you clarify @nyonson how you were intending us to invoke this?

Yea, so the msrv of rbmt is 1.74. I looked into lowering it to 1.63 and its kind of a pain with the clap and toml deps, so if we can keep the complexity confined to the action.yml here I think that would be ideal.

This diff in the psbt repo shows the 2 ways I have been installing it. The new --locked option approach is cleaner, but requires a 1.74+ toolchain is used. The other approach is a 3-step process, but at least confined to the action.yml. It first installs the stable toolchain, then installs rbmt with that, and finally installs the requested toolchain. This takes advantage of the fact that the last installed toolchain becomes the default, so avoids having to use the rustup + syntax everywhere. It is pretty gross, but can be dropped when the MSRV is bumped at least?

[apoelstra]

It is pretty gross, but can be dropped when the MSRV is bumped at least?

I'm not too worried about grossness in the Github CI, to be honest. Let's do it.

[tcharding]

Like a boss Nick, I love it.

[apoelstra]

ACK 9ba5314; successfully ran local tests