✨ Passing auth to Dagger commands can become tedious

nipuna-perera commented 2 months ago

What are you trying to do?

Many commands that I run especially in a corporate environment require authentication of some sort. Typically this is username/password but sometimes it could be a certain file or token too.

Why is this important to you?

When using Dagger modules it's typical to split certain functionality into it's own functions and each function can end up requiring to consumer to enter credentials. Examples:

For a Maven module I'd need compile, test, deploy etc. Each of these commands needs authentication typically in the form of credentials inserted in the settings.xml file which resides in the user's home directory. If I use the mvn CLI directly, it knows to look in my home directory for the settings.xml file. This isn't possible to replicate in dagger unless I explicitly pass the settings.xml file to each command. The alternative to settings.xml is to have the user/pass parameterized as env vars. However, the env vars will have to be passed into each maven command for eg: --user env:ARTIFACTORY_USR --pass env:ARTIFACTORY_PSW
Sonar requires a token. Which needs to be passed into each call.
JFrog CLI requires authentication which has to be passed into each call to interact with Artifatory.
Hashi Vault obviously requires user/pass unless using approle which we can't use locally on developer machines.
For docker images to propagate them to the edge we have to set a property in Artifactory. To do that, every call to publish a docker image we have to pass in the user/pass or a user/token to artifactory.
Other build tools like node and python will also require such auth.

This can become tedious.

How are you currently working around this?

No known workarounds at this point other than passing in user/pass/tokens or files for every command utilizing these CLIs.

theEndBeta commented 2 months ago

This would be fantastic - I consider this a barrier for wide adoption where I work.

The main resource I am concerned with is AWS - between SecretsManager, Parameter Store, ECS, and CodeArtifact, practically all of our commands need AWS credentials. This means two - AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY - for most CI, plus AWS_SESSION_TOKEN token when being run directly by a user with SSO login.

MikaelElkiaer commented 2 months ago

Not a perfect solution, but what I have tried to do in my module is this:

Set up creds in the "Main" module
Utilize the creds in the submodules, setting up a base container used for most functions:

dagger / dagger