onbjerg

Libraries are deployed before the test contract, so the likely cause is that we don't persist libraries we deploy ourselves across forks. cc @mattsse

It should be the case that all things in `foundry.toml` can be configured using `FOUNDRY_*`, e.g. `FOUNDRY_ETH_RPC_URL` in your case Edit: Ah, you want to override the environment variable used?

Still unsure about this, I don't know of any tools that allow this other than DappTools because they used a full bash script for configuration, and I don't think there's...

I mean if Forge auto-loaded `.env` for example

Yes, that's what I mean. I think the main reason I don't like the env vars in `foundry.toml` approach is that it's non-standard TOML and requires us to do a...

I think if we want inline env vars I'd rather go with something standard like `${ENV}`. Additionally, there is a question around how this would work for non-string config since...

This comment might be relevant: https://github.com/foundry-rs/foundry/issues/1457#issuecomment-1147407539

It depends on your shell, but in bash you would prepend the variables like so: `FOO=bar ./my-program` Alternatively you can source your `.env` before running commands: ```sh source .env ./my-program...

I'm not entirely sure what you mean - it is definitely possible to run `source .env` in a CI environment before running the test as well

Only for RPC endpoints in the `[rpc_endpoints]` section