takes less than 3 minutes -- on (I assume) low contention runs, best we keep an eye on this during busier periods!

right now, we have an lcli binary included in the runners image which requires manual updates - how often do these breaking changes occur? if we had a weekly rebuild-trigger with manual option to fire it off, would that work?

adding 2-3 minutes to CI runs hurts me a little I guess :-) but not against it per sé.
just want to clarify that there's probably other means to get there.

how often do these breaking changes occur? if we had a weekly rebuild-trigger with manual option to fire it off, would that work?

Breaking changes are not very often imo. We would have breaking changes when adding new forks or instances like this where we change the local testnet structure.
If we could retrigger at times when we noticed a breaking change, that also is good enough for me.

It's unfortunately not enough to just update the binary more frequently, since in the cases where we introduce a breaking change to lcli in a PR, that PR will never pass CI unless CI compiles it, since we require that exact version of lcli. I don't believe keeping it up to date with unstable is enough.

We would need some kind of logic which checks if there any changes to lcli in the PR, and in those instances compiles it from source, otherwise it's free to use the cached version.

We would need some kind of logic which checks if there any changes to lcli in the PR, and in those instances compiles it from source, otherwise it's free to use the cached version.

Yes, I agree this is the way. I'm going to merge this one for now to unblock #5850

@mergify queue

queue

✅ The pull request has been merged automatically