Correct usage of x-attribution-actor-id / x-attribution-login


We’ve just started playing around with new V2 Pipeline API to trigger Pipelines. We are a little confused over how x-attribution-actor-id and x-attribution-login headers are meant to be used. What should or could we be placing as values on these headers?

We’ve also noticed that when we trigger a pipeline the commit seems to be lost so when viewing the workflows in the U/I we just see a blank space where the commit message should be and also the wrong user avatar, is this related to the headers above?




I also want to know the answer to this. I’ve tried using a colleague’s github username for both of these headers and it still attributes the build to me (the request uses my API key).

Hello! Sorry for the confusion. We’ve updated our docs to reflect that these headers can only be used internally by CircleCI. We’ll improve this further by having internal docs pruned from the publicly generated schema, but for now hopefully the updated description helps identify their purpose.

Thank you for the response @fernfernfern. How would we then specify the user whom triggered the workflow? Currently the wrong user gets assigned the workflow jobs that are triggered.

It’s not possible to set the user at this time. It will always be the user of the key who is triggering the pipeline.

@fernfernfern that doesn’t seem to be the case. Using my API key to trigger a workflow a different users name / avatar is shown on the running pipelines list, it appears to be the organisation owner.

In the case of organisations, with multiple users who need to trigger workflows it’s confusing to see a different user in list of running pipelines.

You’re using a key that you generated from and you’re seeing a different account? That seems a bit odd. Could you submit a ticket so that we can look closer and escalate if need be?

I had a similar problem which lead me to this thread originally, hoping the API would help. I ended up doing something as described here:
It’s a little more work… But it helps you see who is really triggering the workflows.