Granular "trigger build" permissions - restrict who can trigger builds on BranchX or with WorkflowY

#1

Description of the feature request

A granular approach to workflow permissions. The ability to have certain workflows be available to certain users. This distinction can be set by admins/owners of the organizational.

Use case / for what or how I would use it

Let’s say an organization has workflows A, B and C. A and B are used for development, but C publishes the app to a build distribution system. Developers should only be able to run workflows A and B, but only CI admins/leads/whoever can only run C to actually publish the app in order to reduce the chances for confusion/mistakes in publishing development and not final builds.

0 Likes

Rights management per workflow
#2

Hi @ivan_melnikov, thanks for the #feature-request!

We’ll consider this, in the while please keep in mind that you can achieve similar results by assigning Roles to the team members of your project.

Admittedly this isn’t the same though, you couldn’t restrict users from running specific builds or using specific steps, only together or not at all.

0 Likes

#3

Hey ya! Thanks for the reply!
Yeah we already have roles, but it’s more so the granular stuff I’m interested in. :smiley:

1 Like

#4

Hi again!

After discussing this request we felt that we should mention that there is a workaround to make this possible.

You could separate your workflows to partially run on Bitrise, providing access to the necessary people, and you could run the other workflows by committing to your repository, where you can specify access setting more in depth and trigger the more ‘restricted’ workflows directly from there :slightly_smiling_face:

I hope this is a suitable option for you guys, let us know!

0 Likes

#5

Aaah yeah, I can see how that can work too. I’ll take a look at implementing that!

EDIT: Realized I probably misunderstood. Won’t we still run into the issue of having all developers see the restricted workflows too?

0 Likes

#6

Hi @ivan_melnikov,

Only owners and admins can access the workflow editor. If you give developer or tester permission to those who you want restricted from there they won’t see those workflows.

0 Likes

#7

@daniel

Hey ya! So I know that admins and owners can access the workflow editor, but all workflows show up for all developers in the “Start/Schedule a Build” menu, no? What I got from your message was that I can restrict that?

0 Likes

#8

Hy @ivan_melnikov!
A solution would be to separate C workflow to a different app with no webhooks registered to it, that only worker.C can manage and start manually.
so that worker.A and worker.B can not trigger a publish, but can trigger test build A or B.

1 Like

#9

Not the editor, just running workflows. If I create a workflow, all of our developers can run it, and that’s the problem. Even if I split them up, they’re all there to see and just trigger one that can publish a build.

0 Likes

#10

Hello!
yes, as I told: for the protected workflow, create a different app from the same repository.

0 Likes

#11

Any possibility that this feature will be implemented in the near future? You can achieve this by creating a new app, yes, but that is not a long term solution, according to me. Imagine you have 10 apps, each with 3 workflows. If you want to restrict each workflow type to a specific audience, that means that you will end up with 30 apps, instead of 10, which is a bit of a admin nightmare.
I’m really looking forward to using this feature. :slight_smile: Btw, I’m loving Bitrise!

0 Likes

#12

Hi @timothy.devilliers! You raise some good points :slight_smile: This is definitely planned, but also definitely not a priority at the moment. Make sure to bring more votes to change that!

0 Likes