search

0xPolygonMiden / compiler

Compiler from MidenIR to Miden Assembly
MIT License
63 stars 21 forks source link

chore: update rust toolchain and rework ci workflows #322

Closed bitwalker closed 2 weeks ago

bitwalker commented 3 weeks ago

This PR updates our Rust toolchain to a recent nightly (same date as the recent 1.81.0 stable release, 08-06), updates dependencies, and takes the opportunity to address some outstanding improvements/fixes to our GitHub Actions workflows.

See the commit description for the commit that modifies the workflows for details on what the changes are and the rationale behind them.

This closes out #256, and makes rust-toolchain.toml the canonical source for the Rust toolchain that will be used both locally and in CI. If we need to add targets or components to the "base" installation of our toolchain, they should be added there, rather than performed manually. For things like Cargo extensions that we use, cargo-make handles installing them for us, so we don't need manually-defined tasks for those items, except when we need to do something special. For example, we currently install a pinned version of cargo-component, which requires us to define a task to control that.

Since the workflow changes won't take effect until this is merged (IIRC), we may have to iterate on them a bit to fix any issues that come up. Let's prioritize addressing those when they come up, so we can rely on CI being stable.

bitwalker commented 3 weeks ago

Correction: looks like the workflow updates are actually run as part of the PR, so that's great, I can work out the kinks here before we merge

bitwalker commented 3 weeks ago

@bobbinth If you have a moment, and can skim this and review, I'd like to try and get this merged so I can test the interaction with our other PRs and in particular the caching behavior, and then I can get #319 merged as well, and get things unblocked for Denys and I. Not a big deal if you aren't available, but figured its worth a ping 😅

bitwalker commented 2 weeks ago

Thanks @bobbinth!

Also, in other repos we use simple make rather than cargo-make, but if you prefer cargo-make, that's fine too.

We're using cargo-make because it's portable, while make isn't, but it also has several nice features which automate some things in a way that is less fragile as the project evolves. For example, we don't need to explicitly install Cargo extensions we depend on as a pre-requisite, as cargo-make will automatically install any referenced extensions if they are not yet installed. There are a number of other nice-to-have features that will come in handy as the toolchain grows in complexity, but for now things are still relatively simple.