`make clippy` fails locally but not on CI

[igamigo]

Currently, make clippy (as well as cargo build in the workspace root) is failing locally due to some recent changes to miden-base. Here is the error:

error[E0599]: no variant or associated item named `Local` found for enum `miden_objects::notes::NoteExecutionHint` in the current scope
  --> bin/faucet/src/handlers.rs:72:83
   |
72 | ...NoteExecutionHint::Local)
   |                       ^^^^^ variant or associated item not found in `NoteExecutionHint`

For more information about this error, try `rustc --explain E0599`.
error: could not compile `miden-faucet` (bin "miden-faucet") due to 1 previous error
warning: build failed, waiting for other jobs to finish...

The CI (which runs make clippy) however has been passing which could be an issue. This could be related to the new caching action (though I'm not too familiar with how it works).

[igamigo]

https://github.com/0xPolygonMiden/miden-node/pull/434 fixes the faucet build

[SantiagoPittella]

To ensure that we are always running with the latest of miden-base but not removing the cache, maybe we can add an update to all deps from that repo (cargo update {miden-tx, miden-objets, miden-lib}) in the GitHub workflows.

[Mirko-von-Leipzig]

I think we explicitly wanted to decouple updates in miden-base etc from here. i.e. Only update when we decide to do so - otherwise there will forever be churn.

The lockfile should have prevented the issues you're seeing since it pins the commit of miden-base as a dependency. This is also why the ci is passing (nothing to do with the caching I hope 😅).

What I don't understand is how you managed to get a compile issue. You'll notice that your fix in #434 changed the lockfile hashes for miden-base et al, pulling in the new version of it.

Maybe one of

• you ran cargo update locally
• you use a shared cargo cache locally and make clippy does not have --locked so it was happy to use the updated version?

Probably we should at least add --locked to our make commands.