This section details some solutions to common configuration requirements. There are other ways to solve these configuration requirements, and there is no one “correct” solution for any of these, so it is better to think of these as examples of what can be done.
Background.
This example considers the case where there is one team of users owning the single instance. The team consists of multiple people with different roles. The most common roles in this case are:
- Developer - will want to be able to kick off builds and modify job configuration
- Tester - will want to be able to kick off builds, access build artifacts and create SCM tags
- Manager - will want to be able to manage user roles in the team and create projects
- Admin - will want to be able to administer the system
- Read only - will require read access to the system but not be able to download build artifacts
Sample solution.
Create one role for each role of user: developer_role, tester_role, manager_role, admin_role, and reader_role. Additionally, create one group at the root level for each role of user, assigning the corresponding role to each group: developers, testers, managers, admins and readers. Finally add the members to each group as necessary.
Table 8.2. Sample roles for an instance owned by one cross-functional team
Role | Permissions |
---|---|
developer_role |
|
tester_role |
|
manager_role |
|
admin_role |
|
reader_role |
|
Table 8.3. Sample groups for an instance owned by one cross-functional team
Context | Group | Role(s) | Member(s) |
---|---|---|---|
ROOT |
developers |
|
All the developers |
ROOT |
testers |
|
All the testers |
ROOT |
managers |
|
All the manager(s) |
ROOT |
admins |
|
All the administrator(s) of the instance |
ROOT |
readers |
|
|
Background.
This example considers the case where there are multiple teams of users sharing the single instance. Each team consists of multiple people with different roles. The most common roles in this case are:
- Build Manager - will want to be create, modify and delete job configurations
- Developer - will want to be able to kick off their builds
- Tester - will want to be able to kick off their builds, access build artifacts and create SCM tags
- Manager - will want to be able to manage user roles in their teams
- Admin - will want to be able to administer the system
- Read only - any authenticated user will require read access to the system but not be able to download build artifacts
Sample solution.
Create one role for each role of user: builder_role, developer_role, tester_role, manager_role, admin_role, and reader_role. Additionally, create two groups at the root level for the administrators and readers, assigning the corresponding role to each group: admins and readers respectively. Use the folders plugin to create folders for the two teams, and in each folder create groups for the builders, developers, testers and managers of the respective teams. Finally add the members to each group as necessary.
Table 8.4. Sample roles for an instance shared by multiple cross-functional teams
Role | Permissions |
---|---|
builder_role |
|
developer_role |
|
tester_role |
|
manager_role |
|
admin_role |
|
reader_role |
|
Table 8.5. Sample groups for an instance shared by multiple cross-functional teams
Context | Group | Role(s) | Member(s) |
---|---|---|---|
ROOT |
admins |
|
All the administrator(s) of the instance |
ROOT |
readers |
|
|
Team 1 Folder |
builders |
|
All the build managers in team 1 |
Team 1 Folder |
developers |
|
All the developers in team 1 |
Team 1 Folder |
testers |
|
All the testers in team 1 |
Team 1 Folder |
managers |
|
All the manager(s) of team 1 |
Team 2 Folder |
builders |
|
All the build managers in team 2 |
Team 2 Folder |
developers |
|
All the developers in team 2 |
Team 2 Folder |
testers |
|
All the testers in team 2 |
Team 2 Folder |
managers |
|
All the manager(s) of team 2 |
Background.
This example considers the case where there are multiple teams of users sharing the single instance. Each team consists of multiple people with the same role. The most common teams in this case are:
- Development - responsible for developing a single product
- SQA - responsible for testing many products
- DevOps - responsible for deploying many products into production
Sample solution.
Create one role for each role of user: developer_role, sqa_role, devops_role. Then create groups for the sqa and devops teams at the root level assigning the corresponding role to each group: sqa, devops. Use the folders plugin to create folders for each product and within each folder create a developers group assigned the developer_role. Complete the configuration by adding the members of each team as members of the corresponding groups.
Sample roles for an instance shared shared by multiple single-function. teams
Role | Permissions |
---|---|
developer_role |
|
tester_role |
|
devops_role |
|
Sample groups for an instance shared shared by multiple single-function. teams
Context | Group | Role(s) | Member(s) |
---|---|---|---|
ROOT |
sqa |
|
All the people in the SQA team |
ROOT |
devops |
|
All the people in the DevOps team |
Product 1 Folder |
developers |
|
All the developers of product 1 |
Product 2 Folder |
developers |
|
All the developers of product 2 |
Background.
This example considers the case where you want to have a secret project on a shared instance. The project will be worked on by a small team who should be able to see the project, but everyone outside of that team will be unable to see the project.
Note
If somebody has access to the JENKINS_HOME
directory, they will be able to see the secret project. Similarly, by creating an appropriate build script, a non-secret project could gain access to the secret project when building on a file system that the secret project has also built on. If it is absolutely critical that the project remain secret, then it may be best to use a dedicated instance for the project.
For most use cases, however, the project is being kept secret from people who both do not have direct access to the JENKINS_HOME
directory, and do not have access to creating build jobs or modify the source code.
Sample solution.
Create a group in the project (or folder) for the team of people who will be working on the secret project. Add all the roles that the team will require. Add all the members of the team. Modify the role filters for the project (or folder) filtering out every role (or all but the administrator role if administrators are to be allowed to view the project).
Note
If you are configuring a secret project to which you will not have access, once you apply the role filters you will be locked out from the project, and it will appear as if there is no such project. See the section called “Finding hidden projects” for details on how to recover from accidental lock-outs of this type.
It may also be advisable to create a group for admins of the secret project before configuring the role filters if only a subset of those with the overall administrator role are to be able to see the secret project.