Define acronyms on first use, add reference to codeberg-ci/examples, and remove reference to knut org (#435)

- All acronyms should be defined in first use. This adds this for Continuous Integration (CI) and Role Based Access Control (RBAC).
- Changes language around acceptance to soften tone, and shift from guaranteed to conditional acceptance.
- Specifies that login to woodpecker-ci is via codeberg account, and that repositories are automatically available to link.
- Adds reference to codeberg-ci/examples repository.
- Removes reference to knut organization.

Co-authored-by: Patrick Schratz <pat-s@noreply.codeberg.org>
Reviewed-on: https://codeberg.org/Codeberg/Documentation/pulls/435
Reviewed-by: Patrick Schratz <pat-s@noreply.codeberg.org>
Co-authored-by: Mark Pitblado <mark@pitblado.me>
Co-committed-by: Mark Pitblado <mark@pitblado.me>
This commit is contained in:
Mark Pitblado 2024-06-12 20:02:39 +00:00 committed by Patrick Schratz
parent 74e8925bec
commit 193b4cf639
2 changed files with 7 additions and 13 deletions

View file

@ -8,7 +8,7 @@ eleventyNavigation:
Every piece of code should be tested regularly. Ideally developers already implement unit-tests to test the functionality of code sections.
Some projects even implement a suite of integration tests, testing whether the code in different parts of the software works as a whole and (still) provides the functionality the software promises to deliver.
Running these tests regularly (or continuously) is the job of a Continuous Integration solution.
Running these tests regularly (or continuously) is the job of a Continuous Integration (CI) solution.
The results of the tests are displayed to the project members and maintainers, enabling them to identify problems and react if errors occur.
## Using Codeberg's instance of Woodpecker CI
@ -17,28 +17,28 @@ Codeberg provides a [Woodpecker CI](https://woodpecker-ci.org) instance at [ci.c
Onboarding requires a few manual steps, as to prevent the abuse of Codeberg's limited resources.
You will need to request access [by filling out this form](https://codeberg.org/Codeberg-e.V./requests/issues/new?template=ISSUE_TEMPLATE%2fWoodpecker-CI.yaml).
Eventually, a Codeberg volunteer will review your request and grant you access.
After submitting, a Codeberg volunteer will review your request and grant you access if your use case is appropriate.
In order to ensure a fast approval,
please take a minute to read about [the criteria that your project has to adhere to](https://codeberg.org/Codeberg-e.V./requests#woodpecker-ci).
After your request gets approved, you will be able to login to [ci.codeberg.org](https://ci.codeberg.org).
To start builds for your repository, you must enable them in Woodpecker specifically using https://ci.codeberg.org/repos/add.
If your request gets approved, you will be able to login to [ci.codeberg.org](https://ci.codeberg.org) via your Codeberg account.
To start builds for your repository, you must enable them in Woodpecker specifically using https://ci.codeberg.org/repos/add. Repositories owned by your codeberg account should automatically be available as options to select.
### Caveats
For the usage of our Woodpecker instance, keep the following in mind:
- CI access is **provided as-is and might break at any time** and for an undefined period of time, due to server issues, for testing and maintenance purpose or human error.
- **CI access is provided as-is and might break at any time** and for an undefined period of time, due to server issues, for testing and maintenance purpose or human error.
- **Resource usage must be reasonable** for the intended use-case. CI requires substantial computing resources (cloning the repo and pulling the image, installing required tools, building and throwing everything away). Please try to ensure a good balance between code quality/automation and resource usage. Therefore, please consider twice how to create a good balance between ensuring code quality for your project and resource usage therefore.
- The CI service requires manual onboarding and Woodpecker has limited RBAC capabilities, which will be a problem for projects with a team-based permission structure or many individual collaborators.
- The CI service requires manual onboarding and Woodpecker has limited Role-Based Access Control (RBAC) capabilities, which will be a problem for projects with a team-based permission structure or many individual collaborators.
Issues and general feedback should be reported in our
[dedicated Codeberg CI feedback repository](https://codeberg.org/Codeberg-CI/feedback).
### Usage
If you are curious about Woodpecker or are already using a third-party Woodpecker instance,
please consult [Woodpecker's documentation](https://woodpecker-ci.org/docs/intro).
please consult [Woodpecker's documentation](https://woodpecker-ci.org/docs/intro). If you wish to see examples of integrating Woodpecker-CI with codeberg, please consult the [Codeberg-CI examples repository.](https://codeberg.org/Codeberg-CI/examples)
### Custom Woodpecker Instances

View file

@ -22,12 +22,6 @@ There are a number of exceptions to the rule above:
- For major changes, at least two people will need to approve the contribution.
- For changes that are critical, e.g. ones that might legally affect Codeberg e.V., the chairperson of Codeberg e.V. will need to approve of the changes as well.
### Where to create example repositories?
Please create example repositories for the Documentation in the `knut` organization on `codeberg.org`.
If you do not have permissions for that, feel free to ask [in the issue tracker](https://codeberg.org/Codeberg/Documentation/issues).
### How to link to non-existing articles? / Draft Articles
While it is not directly possible to link to non-existing articles, it is possible to create Draft Articles, which are articles that cannot be localized for example via the menu, but which do exist under their URL and do show a message stating that the article is unpublished.