Permissions in pipelines

Every member in the team has their own role. We can distinguish plenty of them: Junior Developer, Senior Developer, Frontend, Backend, DevOps, SysAdmin – you name it.

Each single role determines a member’s duties and permissions and is strictly based on the member’s skills. For instance, a Junior Developer shouldn’t have permissions to release the application to Production, but they should have permissions to deploy to the Dev server.

In this article, we'll show you how to manage permissions in Buddy's pipelines.

Workspace administrator

The Admin role grants access to all projects and pipelines in a given workspace. It's not possible to restrict access permissions to the project for an admin, nor hide pipelines using the visibility.

If you want to give admin rights to a workspace member, you should:

1. Open the People tab: https://app.buddy.works/$workspace/people
2. Go to the profile of the user who you want to grant the admin rights: https://app.buddy.works/$workspaceprofile/$userid
3. Click Set as administrator in the right column

NOTE: Each workspace owner is assigned admin rights by default that cannot be changed. Only an administrator can give admin permissions to other users.

Granting admin rights

Project permissions

There are two permissions defined by default in the workspace: Developer and Read-only.

The first one allows for managing and running pipelines. The second one, as its name indicates, allows only to view the pipelines without the ability to add, edit or run them.

Define your own permissions

You can also define your own permissions within the workspace. This can be done by an admin only. To create your own permission set:

1. Go to Workspace Preferences: https://app.dev.io/$workspacename/workspace
2. Switch to the Permissions tab in the left menu
3. Click Create a new permission

NOTE: If you use Buddy as the hosting service in your projects, you can also define the level of Source access there.

Setting custom permissions

The are four access levels of Pipeline access in Buddy:

1. Denied - user with this level of permissions will not see the Pipelines tab at all
2. View-only - user can browse the executions in Pipelines, for example to check when was the last release to the Production server. However, they cannot run new executions.
3. Run-only - user can trigger new permissions, but they cannot edit the pipeline's settings, eg. change the scripts that are run upon the executing
4. Manage - this access level gives full permissions to the Pipelines tab. A user with this access level has the same access to pipelines as the administrator.

Defining permissions in a project

In general, permissions can be defined for the project’s member. In other words, a workspace member can have various permissions across the projects. To give permissions for a project member, just follow these steps:

1. Go to the Project Options
2. Find the Team tab: https://app.buddy.works/$workspacename/$projectname/team
3. Find the Select link next to the chosen project member to choose any wanted permission

NOTE: An administrator has the Developer role set by default, which means that he has full rights in the project. It’s not possible to change permissions for the admin.

Defining permissions in project

Pipeline’s visibility

Apart from permissions that define the access level to all pipelines in a given project, you can also set the Pipeline’s visibility. Thanks to that, you can restrict the pipeline’s visibility to a defined group of project members.

In order to set the visibility:

1. Go to the Pipeline’s Settings
2. Extend More Options – you’ll find the Visibility option there

NOTE: It's not possible to restrict visibility for administrators.

Defining pipeline visibility

Running pipelines on every push vs. Permissions

You can set various trigger modes in the pipelines: manual, on every push (automatic), and recurrent.

However, if we use the automatic mode, the pipeline will be triggered after every single push, no matter if the user what permissions and visibility the user has. In short, the trigger mode has the highest priority of all.

---

Use case #1

There are three pipelines in the project:

• DEV Server - automatically builds and deploys the application to the DEV server on every push
• STAGE Server - releases the application to the STAGE server once a day + runs integration tests
• PRODUCTION Server - releases the application to the PRODUCTION server

With such setup applied, you should have three set of permissions applied:

• Junior Developer - cannot manage the pipelines, but is able to push to the branch that triggers the deployment to the DEV server
• Senior Developer - has full control over the pipelines and is allowed to deploy the application the STAGE server, as well as perform the release to Live (manually on click)
• Client - has view-only permissions with visibility settings that allow him to see only the Production server with the latest release of his application

Use case #2

There is one person in the team that manages servers and pipelines: the Deployment Manager with the Manage access level.

Apart from that, there's the Senior Developer who can run manual deployments to the production server. However, she cannot edit the deployment scripts, because she has Run-only access level.

The last one is a Junior Developer, who also has Run-only access level, but cannot see the production server, nor deploy to it (the server is hidden with visibility settings.