Make person who triggered a manual build available in an ENV variable

#1

Description of the feature request

The name of the person who triggered a manual build available in an environment variable

Use case / for what or how I would use it

For auditing or otherwise understanding what triggered a build it would be nice to have the name of the user available.

0 Likes
How to conditionally route Slack notifications
#2

Thanks for the #feature-request @adebree! :slight_smile:

May I ask why you need this information in the build / during the build instead of via e.g. the API? I’d imagine for auditing an API option would be better than an env var during the build :thinking:

0 Likes
#3

Maybe in order to show it on Slack message?

3 Likes
#4

@viktorbenei Exactly wat @bernat says! My primary use case is showing it in slack messages, and secondary use case is to have it available in build logs.

1 Like
#5

@viktorbenei we also wanted access to this for the same reason above.
In our slack message we wanted to mention who triggered a manual build.

So this would be the bitrise account name (or even better the First and Last Name if you have that) of the person who manually triggered the build.

1 Like
#6

Bumping this. I also have Slack notifications as my primary use case, but this could be generally-useful, as I proposed to @fehersanyi-bitrise:

The feature I’m requesting is simply an environment variable that is present when someone manually triggers a build, which includes information about the Bitrise user that triggered it

This can then be used in workflow scripts, for example: a BITRISE_TRIGGER_SOURCE environment variable that could be “0” for “Webhook”-triggered builds, “1” for “Scheduled”, maybe “3” for manually-launched workflows, etc.

In the manual case, Bitrise could also provide other env vars, e.g. BITRISE_TRIGGER_USER, BITRISE_TRIGGER_EMAIL, etc., which would respectively include the username, email address, etc. of the user who launched the workflow.

Beyond notification routing, this information could also be used as input to build steps that might generate custom artifacts, apps, etc.

1 Like
#7

I would also like to give a big :+1: for this feature.

3 Likes
#8

Hi
sorry, any update regarding this acclaimed feature?

0 Likes
#9

Hey guys, any update for this feature yet?

0 Likes
#10

+1 though I’d go further and make a Slack app that would allow to invoke Bitrise builds through API, then this info will be available in build parameters or environments (haven’t checked how Bitrise API approaches that but I suppose it would be something like that)

0 Likes