User defaults interfere with codegen

[thick snow]

🤔🤔🤔

This was discussed as we designed user defaults, if I remember correctly. I guess it never came up as a practical issue as long as codegen was done dynamically... But now that we're striving to decouple codegen from runtime... It appears to become an issue after all

At the time we briefly considered not injecting user defaults as default values in the schema, and handling it as a separate layer. But opted for schema injection to avoid having too many different layers. Maybe your codegen misadventure (different user defaults causing different incompatible clients to be generated) is a sign that we should adjust that aspect of the design...

@analog matrix btw why remove .env in ci?

[analog matrix]

In CI we authenticate to AWS via an IRSA token which is present on the self hosted runner. Locally we use the AWS credentials file. We have two seperate parameters on our modules for accepting one of these secrets and both are marked as optional.

For the local experience the .env file is set up to point to the AWS credentials file. On the CI runner this file does not exist and so parsing of the .env file fails. To keep things simple, we remove the .env file and opt to supply every parameter explicitly in CI, getting around this problem.

We could potentially still be using the .env file in CI if you were able to pass a specific .env file via a flag: --env-file=.env.ci... however this is probably adjacent to the codegen problem

You might still end up with different codegen

[thick snow]

what if I told you .dagger/config.toml (workspace config) will support multiple environment config in a single file 😇

dagger --env=my-ci

[analog matrix]

That would be good... can host values be passed in ??

i.e. the ssh socket, host secrets

[thick snow]

yes

it will auto-detect & migrate user defaults from .env

[analog matrix]

So does this workspace v2 effectively deprecate .env or does it need .env as well?

[thick snow]

it deprecates it (but with backwards compat for continuity)

.env has made it more difficult than expected to guess the right env var names. And the "maybe don't track in git" convention for .env is not as good a fit as we thought, since Dagger user defaults, although not as portable as modules, are safe to check in.

[echo violet]

What I like the most about the new system is that they can be generated and managed via the CLI.