Consider fixing Foundry version across GitHub workflows using an an env variable

[arthurgousset]

Question re Github workflows and Foundry versions:

I see that we're installing foundry in at least 3 different workflows:

1. celo-org/celo-monorepo > workflows/protocol-devchain-anvil.yml
2. celo-org/celo-monorepo > workflows/protocol_tests.yml
3. celo-org/developer-tooling > workflows/ci.yml

We're currently fixing foundry version at nightly-f625d0fa7c51e65b4bf1e8f7931cd1c6e2e285e9.

I expected the foundry version will change frequently, as we'll want to keep up with the latest Foundry releases.
Unfortunately, we can't currently stay on the latest version, because it introduced a regression that breaks our workflows.

Question: Does it make sense to set the Foundry version in one place so it can be fetched by all workflows?

My thinking:

1. Con: I can see a downside where some versions work with some workflows and not with others. So it might be best to keep versions independent.
2. Pro: I can see a benefit where we want to upgrade in lock-steps and some workflows will fail because we forgot to upgrade the version.

[lvpeschke]

I would advocate to keep a single version. It makes reasoning about workflows simpler, reduces the probability of forgetting to update in an odd place, and adds a forcing function to solve bugs by blocking a general upgrade. That is, if Foundry is more or less used for the same things in all these places.

Where different versions could make sense to me:

• stable vs experimental environments
• working on different forks and inheriting their different versions

[arthurgousset]

Sounds good, thanks for the input @lvpeschke. I made an issue, and will open a PR to do this:

• Fix Foundry version across GitHub workflows #11032