• Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      Hi team,

      We have had a community customer reach out and request that runners be configurable at the project-level.
      At present, we can only configure runners at the workspace-level and repository-level, project-level runners would allow sharing of runners between a subset of repositories rather than the entire workspace.

      Cheers!

      • Ben (Bitbucket Cloud Support)

            [BCLOUD-22772] Project-level runners

            We use one workspace for a fairly large department. Within this, each team will work with one or more projects, which in turn will contain multiple runners.

            Presently, we have to maintain a set of "global" runners which we setup on the workspace for everyone to use - but there are instances where teams would like to have their own set of runners for their own repositories. Setting up runners per repository isn't great here, because they cannot be resused by another repository. Ideally a team would be able to setup a pool of runners, which they look after by themselves and can use across all their repositories. Project level runners would really help here.

             

            At the moment, the best thing I can think of is to setup team owned runners on the workspace, and then use one label for each team - but this isn't great, because it means a team member needs to be a workspace administrator to setup their runner (which is not great) plus there is nothing to stop any pipeline stealing a runner that is not meant to be used that pipeline (e.g. if I just specify I want a linux runner, I'll get any linux runner, regardless of whether it had a team label or not, so I could accidentally steal a runner that should be reserved for a specific team.

             

            Martin Cassidy added a comment - We use one workspace for a fairly large department. Within this, each team will work with one or more projects, which in turn will contain multiple runners. Presently, we have to maintain a set of "global" runners which we setup on the workspace for everyone to use - but there are instances where teams would like to have their own set of runners for their own repositories. Setting up runners per repository isn't great here, because they cannot be resused by another repository. Ideally a team would be able to setup a pool of runners, which they look after by themselves and can use across all their repositories. Project level runners would really help here.   At the moment, the best thing I can think of is to setup team owned runners on the workspace, and then use one label for each team - but this isn't great, because it means a team member needs to be a workspace administrator to setup their runner (which is not great) plus there is nothing to stop any pipeline stealing a runner that is not meant to be used that pipeline (e.g. if I just specify I want a linux runner, I'll get any linux runner, regardless of whether it had a team label or not, so I could accidentally steal a runner that should be reserved for a specific team.  

            In our company we use one workspace, with multiple projects/teams. Each team should use one runner. It's very annoying, to configure runners for each repository!

            It would bei great, if you can provide feedback on whether runners are scheduled at the project level.

            Matthias Vogt added a comment - In our company we use one workspace, with multiple projects/teams. Each team should use one runner. It's very annoying, to configure runners for each repository! It would bei great, if you can provide feedback on whether runners are scheduled at the project level.

              Unassigned Unassigned
              57b7f67f3625 Ben
              Votes:
              33 Vote for this issue
              Watchers:
              12 Start watching this issue

                Created:
                Updated: