Community Tooling
This repository contains tools to handle our community, like our peribolos-config-merger.
Releasing
Create a GitHub Release with a tag in the format of v<major>.<minor>.<patch>
and this will trigger the automatic releasing process.
Tools
Peribolos config merger
The merger contains our custom generation logic for the peribolos configuration.
Within the config
directory, we are storing our configurations.
(this can be overwritten with a config flag (--config
) when executed).
Configuration Structure
Each directory within the config
directory represents a GitHub Organization (therefore we will refrain from it as org-folder
).
This directory will only be picked up when there is a org.yaml
within the directory.
Within this org-folder
we can have multiple teams/workgroups.
Those teams are represented with their subfolder (the name of the team) containing a workgroup.yaml
.
The merger will fetch these configurations and generate a proper peribolos configuration based on this.
org.yaml
The org.yaml
follows the default peribolos configuration format.
It will be used to:
- define members and admins of the organization
- define default settings for the organization such as:
- members allowed to create repositories
- default permissions for members
- ...
- repositories and their configuration
- global teams
special teams
There are 3 special teams within the org.yaml
.
<workgroup>/workgroup.yaml
Each workgroup represents an organizational unit, which needs to work on the same repositories.
A workgroup consists of following roles:
- approvers (triage permission)
- maintainers (maintain permission)
- admins (admin permission)
Based on the definition above a workgroup.yaml
has the following structure:
repos: # a list of repositories the team has access to
- repo-1
- repo-2
approvers:
- approver-1
maintainers:
- maintainer-1
admins:
- admins-1
Repositories are not mutually exclusive to workgroups. Hence, multiple workgroups can have access to the same repositories.
Note Use admins carefully and only when it is really needed. Admins can change secrets etc.
Based on this configuration we will generate 3 teams:
- <workgroup>-approvers
- <workgroup>-maintainers
- <workgroup>-admins
Furthermore, we will assign those 3 teams also permissions for the defined repositories.
Example
Let's say we have a workgroup.yaml
within org-folder/workgroup
.
The content is:
repos:
- repo-1
approvers:
- approver-1
maintainers:
- maintainer-1
admins:
- admins-1
Following Teams will be generated, with the respective permissions for the repository repo-1
:
- workgroup-approvers: triage
- workgroup-maintainers: maintain
- workgroup-admins: admin