banner VS cargo-msrv

Turns out I’ve been hacking on https://github.com/rustl3rs/banner; a CI/CD system; for 3 months now. Haven’t been this into an out of work project in decades. I just keep setting really small goals, and if the animals wake me up early, I hack on that goal until it’s ready. Commit; repeat. Very happy with the progress. Some of the current progress has seen the capability to set env vars and use host directories in a task. Next step is to be able to pass the state from one task to another; at which point it will pretty much be able to dogfood itself. 🐶🦴

I'll be continuing to think and hack on Banner; my thoughts, and now code on how a CICD system should work. It has come a surprisingly long way in such a short time. It's certainly not feature complete, but it has been capable of running a test (unit-test; which could conceivably run unit-tests) for a little while. My current focus is constructing event handlers for simple cases, and allowing them to be executed when a matching event is emitted. Thinking to write the handler as a rhai script, and execute the compiled ast. But rhai isn't particularly async friendly, so may have to shift my thinking. Just started looking at Rune and it looks promising.

I’m starting to formulate some ideas I’ve had for a long time around CI/CD. No guarantees it’ll go anywhere, but I find it pretty hypocritical that we advocate for testing the skin off our code before we accept it as production ready, but then basically test in production the pipelines that deliver that automation. There just aren’t easy ways to test a pipeline before you merge it or before you make the change in production. Your pretty much forced into a practice we all dislike. Anyway, thoughts here: https://github.com/rustl3rs/banner

What this tool say? https://github.com/foresterre/cargo-msrv

I'm working on cargo-marv.

Before getting overcome by despair, have a look at cargo-msrv -- this little gem of a tool figures it all out for you!

I'll be adding a 'minimal' output format to cargo-msrv for use in scripts. I'll also be updating the book, and inch closer towards releasing v0.16.

First commit 2 months ago, started with edition 2021. https://hg.sr.ht/~cyplo/legdur/browse/Cargo.toml?rev=ca11815...

Have you tried compiling something less than bleeding edge, with a year old compiler, or are you picking projects specifically to "showcase" the supposed failings of the Rust compiler?

Many libraries in the ecosystem have a MSRV (minimum support rust version) guarantee, with compile-time shims to enable newer features if a more recent version is detected.

You can pin your dependencies to those versions (and if they don't have an explicit MSRV, just pin it to a version by date or by running https://github.com/foresterre/cargo-msrv on the project to find the effective MSRV).

You can cargo install specific versions of a binary crate, and if they move to the 2021 edition, or use a recently stabilized standard library function or w/e, you can simply choose to install a specific version, that would work with your distro's rustc/cargo.

I'm not even talking about the completely valid, but last resort strategy of many non-bleeding edge distro package maintainers, of simply creating a .patch file and applying it. In legdur's case, --- edition = "2021" +++ edition = "2018" on Cargo.toml would probably do the trick. For libraries/binaries you control, you can use https://doc.rust-lang.org/cargo/reference/overriding-depende... and https://github.com/itmettkeDE/cargo-patch.

Giving up after the first minor roadblock and crying bloody murder is intellectually lazy.

Looks helpful though it doesn't seem to address when you don't have a Cargo.lock. I've created an issue for this.

I'll be switching over the CLI of cargo-msrv, from Clap's builder methods to the attribute macro. I hope this will simplify the configuration, as my Config and ConfigBuilder structs (which were build from Clap's ArgMatches) was growing fast, and becoming slightly unorganized. With the attribute macro, the config will be constructed directly by code generated by the macro. The mostly saves one intermediate step, and a lot of boilerplate.

Some combination of cargo-outdated and cargo-msrv could probably do this in a slightly more manual fashion.