generated from pool/new_package
Compare commits
1 Commits
| Author | SHA256 | Date | |
|---|---|---|---|
| 43250b4226 |
@@ -1,72 +1,27 @@
|
||||
# Centralized Group and Maintainership Management
|
||||
# Centralized Group Management for Bots
|
||||
|
||||
Reference: https://github.com/openSUSE/openSUSE-git/issues/140
|
||||
|
||||
## Overview
|
||||
|
||||
This document outlines a process for managing OBS group and maintainership data in a centralized Git repository. This approach provides a single source of truth for bots and other automation tools that rely on group and maintainer definitions.
|
||||
This document outlines a process for managing OBS group and maintainership data in a centralized Git repository. This approach provides a single source of truth for bots and other automation tools that rely on group definitions.
|
||||
|
||||
## Group Synchronization from OBS
|
||||
## Synchronization from OBS
|
||||
|
||||
- **Sync Target**: A standalone script will synchronize all OBS groups to a dedicated `obs/groups` Gitea repository. This synchronization is strictly one-way, from OBS to Gitea.
|
||||
- **Storage and Format**: Each group will be stored as a separate JSON file within the repository (e.g., `my-group.json`).
|
||||
- **Data Immutability**: The synchronized group data within Gitea is considered read-only. A Gitea Action will be implemented to prevent direct modifications (e.g., commits or pull requests) to these JSON files. This enforces OBS as the single source of truth for group membership and avoids the complexity of two-way synchronization.
|
||||
- **Drift Detection**: A recurring job will periodically check for divergences between the `obs/groups` repository and OBS. If a drift is detected, the job will automatically open a pull request with the necessary changes fetched from OBS.
|
||||
- **Sync Strategy**: A standalone script will synchronize all OBS groups to a dedicated Gitea repository.
|
||||
- **Drift Detection**: A recurring job, such as a Gitea Action or cron job, will periodically check for divergences between the Gitea repository and OBS. If a drift is detected, the job will automatically open a pull request with the necessary changes.
|
||||
|
||||
## Gitea-Native Groups
|
||||
## Data Consumption
|
||||
|
||||
In addition to the groups synchronized from OBS, it is possible to define custom groups directly within Gitea to manage permissions and maintainership.
|
||||
- **Bot Consumption**: Bots will retrieve group information from files within the `obs/groups` repository. The exact file format (e.g., `GROUP_NAME.yml`) is yet to be determined.
|
||||
- **Package Maintainership**: Package ownership will be defined in a `_maintainership.json` file. This file will map packages to their respective maintainers, who can be individuals or groups.
|
||||
|
||||
- **Creation**: These groups can be defined and managed in their own Git repositories.
|
||||
- **Naming Constraint**: Group names must be globally unique. A Gitea-native group **cannot** have the same name as any group synchronized from OBS.
|
||||
- **Enforcement**: A Gitea Action or pre-commit hook should be implemented to validate any new or modified Gitea-native group. This check will ensure its name does not collide with the list of existing group names from the `obs/groups` repository.
|
||||
|
||||
## Maintainership Data Format
|
||||
|
||||
Package and project ownership will be defined in a `_maintainership.json` file within the repository. This file will map packages to their respective maintainers, which can be individuals or groups. This self-contained format is designed to be easily parseable and self-explanatory.
|
||||
|
||||
The format is determined by inspecting the file: if a `header` field is **not** present at the root of the JSON object, the file will be parsed as the legacy format described below. Otherwise, the new format is used.
|
||||
|
||||
**Example `_maintainership.json` (New Format):**
|
||||
|
||||
```json
|
||||
{
|
||||
"header": {
|
||||
"document": "obs-maintainers",
|
||||
"version": "1.0"
|
||||
},
|
||||
"project": {
|
||||
"users": ["project_owner1", "project_owner2"],
|
||||
"groups": ["project-maintainer-group"]
|
||||
},
|
||||
"packages": {
|
||||
"package1": {
|
||||
"users": ["user1", "user2"],
|
||||
"groups": ["pkg1-maintainers"]
|
||||
},
|
||||
"package2": {
|
||||
"users": ["user3"],
|
||||
"groups": ["pkg2-maintainers"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Structure Explanation:
|
||||
|
||||
* **`header`**: Contains metadata about the file, such as the document type and version. Its presence indicates the new format.
|
||||
* **`project`**: Defines the default owners for the entire project. This includes lists of `users` and `groups`.
|
||||
* **`packages`**: An object containing individual entries for each package. Each package entry can specify its own list of `users` and `groups` as maintainers.
|
||||
|
||||
### Backward Compatibility: Legacy Format
|
||||
|
||||
The legacy format is a simple JSON object where each key represents a package name, and its value is an array of strings representing the user and group maintainers. An empty string as a key (`""`) defines project-level maintainers.
|
||||
|
||||
**Example `_maintainership.json` (Legacy Format):**
|
||||
```json
|
||||
{
|
||||
"": [ "project-maintainer" ],
|
||||
"package-a": [ "user-1" ],
|
||||
"package-b": [ "user-2" ]
|
||||
}
|
||||
```
|
||||
**Example `_maintainership.json`:**
|
||||
```json
|
||||
{
|
||||
"packagename": [
|
||||
"@group_name",
|
||||
"user_name"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
@@ -19,3 +19,49 @@ For example, if a core library like `openssl` (part of Ring0) is updated, all ot
|
||||
- **Note on Performance:** To avoid slowing down Gitea, packages in the repository will be sharded into subfolders based on alphabetical grouping (e.g., folders for `a*` packages, `python-*` packages, etc.).
|
||||
|
||||
- To replicate the Factory team's current use of the `bootstrap_copy` aggregate in the new dynamic `:PR` staging projects, a new intermediate project will be created. This project will aggregate packages from Ring0, and will then be used as the source for the `bootstrap_copy` aggregate within each `:PR` project.
|
||||
|
||||
## Current Setup To Review
|
||||
|
||||
### Build Staging Definition
|
||||
|
||||
The main configuration file is read from (staging.config)[https://src.opensuse.org/openSUSE/Factory/src/branch/main/staging.config].
|
||||
|
||||
The `ObsProject` is where the Factory git (the git providing this file) is build. Currently only a few selected packages are
|
||||
referenced there.
|
||||
|
||||
The `StagingProject` is the root of all staging projects. This includes the templates and also the temporary created projects
|
||||
for test builds.
|
||||
|
||||
The `QA` area currenlty only defines two projects. Both of them get created when the referenced Label is set on a pull request.
|
||||
|
||||
The staging bot is copying the project meta and checks for project links or repository pathes which may need to get adapted.
|
||||
For example the `openSUSE:Factory:PullRequest:1-MinimalX` template is copied as `openSUSE:Factory:PullRequest:PR_NUMBER:MinimalX`. In addition the project link pointing to `openSUSE:Factory:PullRequest` gets converted to `openSUSE:Factory:PullRequest:PR_NUMBER`. Also the `images` path which builds against the `standard` path of same project gets the new project name. Therefore the images and products inside of `images` are using the binaries built in the `standard` repository of the very same pull request project.
|
||||
|
||||
The `openSUSE:Factory:PullRequest:1-MinimalX` template is currently not git based. This allows us to
|
||||
|
||||
- use the existing production `openSUSE:Factory:Rings:1-MinimalX` and `openSUSE:Factory:Rings:0-Bootstrap` sources
|
||||
|
||||
- also an overlay of the package sources already available in `openSUSE:Factory:PullRequest:PR_NUMBER` to use them for a full bootstrap.
|
||||
|
||||
The `openSUSE:Factory:PullRequest:0-Base` template is already git based. However, it only provides a single aggregate file. The repository is set to `rebuild=local`. This has the effect that the base binaries are only take once during project creation for a stable snapshot of binaries. This decuples the pull request projects and avoids blocked states or unwanted rebuilds. However, in case the release manager wants to update the base binaries, he can trigger a rebuild of the aggregate. This QA project is also always created when the MinimalX QA project is wanted. Therefore it is based on the same gitea Label. It needs to be before the MinimalX definition in the `staging.config` file, because the MinimalX is referencing it. So the setup order matters.
|
||||
|
||||
## Further Staging Options
|
||||
|
||||
### Full Rebuild
|
||||
|
||||
We could add a template (project meta and gitea label) which rebuilds entire factory. That would be very resource consuming,
|
||||
but may be important eg. on bigger gcc or rpm updates.
|
||||
|
||||
### Dependend Rebuild
|
||||
|
||||
We could have a template which only rebuilds all packages depending on a certain package. This can be useful to easily test builds which are higher on the dependency stack. For example all golang or all KDE packages.
|
||||
|
||||
### Specific QA images
|
||||
|
||||
For example kiwi appliance images or docker containers for public cloud or kubernetes tests
|
||||
|
||||
### Non-Goals
|
||||
|
||||
Individual grouping of packages should *not* be done via templates. Instead the release manager should group the package
|
||||
pull requests into a single factory pull request.
|
||||
|
||||
|
||||
@@ -477,7 +477,7 @@
|
||||
|
||||
<!-- Slide: Useful Links -->
|
||||
<section data-background-image="assets/other-pages.svg" data-background-size="auto">
|
||||
<h2>Useful Resources</h2>
|
||||
<h2>Useful Links</h2>
|
||||
<ul style="text-align: left; font-size: 0.9em;">
|
||||
<li><strong>GitHub Kanban Board:</strong> <a href="https://github.com/orgs/openSUSE/projects/11/views/1?filterQuery=label%3AMVP">https://github.com/orgs/openSUSE/projects/11</a></li>
|
||||
<li><strong>GitHub Issues:</strong> <a href="https://github.com/openSUSE/openSUSE-git/issues">https://github.com/openSUSE/openSUSE-git/issues</a></li>
|
||||
@@ -486,7 +486,6 @@
|
||||
<li><strong>obs-scm-bridge documentation:</strong> <a href="https://openbuildservice.org/help/manuals/obs-user-guide/cha-obs-scm-bridge">https://openbuildservice.org/help/manuals/obs-user-guide/cha-obs-scm-bridge</a></li>
|
||||
<li><strong>External Documentation:</strong> <a href="https://src.opensuse.org/openSUSE/git-workflow-documentation">https://src.opensuse.org/openSUSE/git-workflow-documentation</a></li>
|
||||
<li><strong>Internal Documentation:</strong> <a href="https://src.suse.de/SUSE/git-workflow-documentation">https://src.suse.de/SUSE/git-workflow-documentation</a></li>
|
||||
<li><strong>Slack Channels:</strong> #proj-framework-one and #proj-framework-one-git-packaging</li>
|
||||
</ul>
|
||||
</section>
|
||||
|
||||
|
||||
Reference in New Issue
Block a user