Add ${user.name} property about digdag HOT 7 CLOSED

add it to where?

from digdag.

So that we can use this variable inside digdag.yml

from digdag.

hm...I thought that the behavior should be exactly consistent as long as workflow definition is same. Embedding user name conflicts with that principal....but I understand that it's useful.

There're some others such as hostname, pid, path to home directory, digdag version, etc.

from digdag.

If workflow is uploaded to a server, what do we expect for ${user.name}...?
It should be maybe the local user name who ran digdag start command. If it's a scheduled session, it's maybe the user who uploaded the schedule.
But this means that digdag server needs to store those information on DB. Hm....that's complicated.

from digdag.

that's complicated

Agreed.

We can revisit this issue if Digdag will manage the name of owner or uploader of sessions.

from digdag.

I think this will be related to audit logging.
When audit logging is implemented, anyways digdag server needs to track "who started this workflow?", "from which IP?" and "when the REST API called?" (and maybe "using which API key ID?"). I think it's ok to expose those information to workflow as built-in parameters like ${user.name}, ${user.ip}, ${user.hostname} etc.

In this case, ${user.name} (or perhaps ${user.id}, because it should be impossible to camouflage) will return "digdag" or something special when a session is triggered by a schedule. Then, we need another variable like ${user.definer} that runs the user who uploaded the revision of the workflow.

Yes, I think we need to revisit this issue when Digdag implements audit logging architecture.

from digdag.

Close the old issue. Please reopen or file new one if you need.

from digdag.