gusty sonnet
I'm using Azure Pipelines.
I want to avoid having to set environment variables on each function.
So I'd like to code in a list of what I want pulled from host such as "TF_BUILD", "SOURCE_REPOSITORY_NAME" and a few others for example, not have to pass in via CLI switches as these are consistent in certain environments.
Is there a way to do this without having to map in myself?
If not I'm assuming I have to abstract this and write my own conditional logic to process "if CI vs local".
gusty sonnet
Bump so it's not lost. I think this might have been missed to company event that happened at same time.
umbral summit
I've seen other questions about loading many env vars and iirc the simplest solution seemed to be to dump them to a file and load that into dagger. I don't know if there's a way to tell dagger "take this list of env vars", but it might be an interesting idea for a dagger.json config item, maybe similar to how turborepo does it: https://turbo.build/repo/docs/crafting-your-repository/using-environment-variables
weary rapids
I've seen this so many times that I think it deserves its own issue. I guess the tricky part is how to keep this model secure and intentional. Imagine that we allow module creators to somehow specify this in the dagger.json file. In that case, we'd have to come up other safe guards so bad actors don't try to "steal" someone secrets by automatically loading AWS_ACCESS_KEY or similar env variables
I kind of like about the fact that each dagger call is intentional about what its inputs are, but at the same time also understand that it becomes cumbersome relatively easy.
ref: https://github.com/dagger/dagger/issues/6723
and https://github.com/dagger/dagger/issues/8428
umbral summit
I've seen this so many times that I think it deserves its own issue. I guess the...
Yeah I think the difficult part is I might want 10 env vars loaded in one call, and none in another. The script discussion seems promising-the simple aliases is good enough for my use cases, but there are (potentially) lots of use cases to consider!
gusty sonnet
I like the intentionality, it's just that it's tedious initially so was trying to figure if better way to map in. It's very wordy and while a CI can do this, it's a VAST difference from the mage publish i normally would do that would vet specific environment variables exist and do checks.
In this case it's almost like me having to write mage publish --github-token foo --registry myregistry --docker-target foo --config dev .... etc --export-path ./artifacts/foo.tar.gz and more. This gets so unwieldy its not something I can hand to someone to execute, they have to depend on a readme or have another wrapper to call which defeats the goal.
Not asking for any specific change, but more just chatting about some painpoints as I try see where this fits in better.