Add ${user.name} property

[xerial]

To know who is running/submitting the workflow.

[frsyuki]

add it to where?

[xerial]

So that we can use this variable inside digdag.yml

[frsyuki]

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.

[frsyuki]

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.

[xerial]

that's complicated

Agreed.

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

[frsyuki]

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.

[yoyama]

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