https://github.com/open-feature/community-tooling
Tools for Community Management
https://github.com/open-feature/community-tooling
Last synced: about 1 year ago
JSON representation
Tools for Community Management
- Host: GitHub
- URL: https://github.com/open-feature/community-tooling
- Owner: open-feature
- License: apache-2.0
- Created: 2023-03-28T18:04:58.000Z (over 3 years ago)
- Default Branch: main
- Last Pushed: 2025-04-09T17:10:02.000Z (over 1 year ago)
- Last Synced: 2025-04-09T18:26:45.251Z (over 1 year ago)
- Language: Go
- Homepage: https://openfeature.dev
- Size: 198 KB
- Stars: 4
- Watchers: 12
- Forks: 2
- Open Issues: 3
-
Metadata Files:
- Readme: README.md
- License: LICENSE
- Codeowners: CODEOWNERS
Awesome Lists containing this project
README
# 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..` 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:
```yaml
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:
```yaml
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