Updated the Code contribution documentation

Applied some small textual improvements and fixed typo.

Signed-off-by: Lenz Grimmer <lenzgr@noreply.codeberg.org>
This commit is contained in:
Lenz Grimmer 2021-05-13 13:49:19 +02:00
parent 3441374445
commit 98ecb8dfba

View file

@ -6,20 +6,21 @@ eleventyNavigation:
---
Hey there, thank you for heading here and your interest in improving Codeberg. This page is intended to give you a quick start on how and where to contribute code to the platform of Codeberg itself. Some things are always changing and we're not (yet) good at continously updating the docs on that - but we're always glad to help you with your questions. Just reach out and ask!
Since Codeberg uses Gitea as a base, most features that go beyond configuration changes are required upstream and every helping hand is very welcome to improve Gitea and thus Codeberg.
Since Codeberg uses [Gitea](https://gitea.io/) as a base, most features that go beyond configuration changes are required upstream and every helping hand is very welcome to improve Gitea and thus Codeberg.
Gitea itself is written in [Go](https://en.wikipedia.org/wiki/Go_(programming_language)), so it's best to make yourself familiar with this language first. It's focused on being a very easy and maintainable language, so it should not be a big issue if you haven't heard of it yet.
## Where do patches go?
We currently sort patches on the following criteria:
- changes in deployments and config goes to the [Codeberg/build-deploy-gitea](https://codeberg.org/Codeberg/build-deploy-gitea) repo. It holds the scripts used to set up the Codeberg instance and overrides other changes, so have a look at it in any case!
- changes that benefit the general gitea userbase should go into the [upsteram repo](https://github.com/go-gitea/gitea). Contributions there also help improving Codeberg, so consider raising a merge request there to help all instances of Gitea
- a small set of patches is directly committed into the [Codeberg/gitea](https://codeberg.org/Codeberg/gitea) repo, these include
- (non-configurable) template changes or small tweaks that are not intended for upstream
- hot-fixes for urgent issues (like anti-spam measures) that are sometimes low quality and thus not upstream, but would require a proper solution in the software itself
- backports of gitea commits with important features or fixes that won't be officially backported
- cherry-picked commits of pending upstream PRs we want to include sooner
- Changes in deployments and config goes to the [Codeberg/build-deploy-gitea](https://codeberg.org/Codeberg/build-deploy-gitea) repo. It holds the scripts used to set up the Codeberg instance and overrides other changes, so have a look at it in any case!
- Changes that benefit the general gitea userbase should go into the [upsteram repo](https://github.com/go-gitea/gitea). Contributions there also help improving Codeberg, so consider raising a merge request there to help all instances of Gitea
- A small set of patches is directly committed into the [Codeberg/gitea](https://codeberg.org/Codeberg/gitea) repo, these include
- (Non-configurable) template changes or small tweaks that are not intended for upstream
- Hot-fixes for urgent issues (like anti-spam measures) that are sometimes low quality and thus not upstream, but would require a proper solution in the software itself
- Backports of gitea commits with important features or fixes that won't be officially backported
- Cherry-picked commits of pending upstream PRs we want to include sooner
## Getting started
@ -29,23 +30,23 @@ So let's put our hands-on and start hacking. If you don't already have an issue
The deployment of Codeberg is handled via the [Codeberg/build-deploy-gitea](https://codeberg.org/Codeberg/build-deploy-gitea) repository which also contains the code of the Codeberg pages feature. While there's some work on different deployment approaches (more to that later), this is the way stuff is handled as of today.
The deployment Makefile connects to a remote server via ssh, so we recommend configuring a virtual machine for this. You can use the provided script or perform the following tasks inside your favourite VM / container solution:
- add a user and group git
- provide SSH to root
- setup a MySQL database `gitea` end enter the credentials into your app.ini
- install at least git make nodejs npm openssh-server librsvg2-bin (example package names from Debian Buster)
- run the makefile and see that Gitea is installed, you can override variables and run it like `make HOSTNAME_FQDN=localhost deployment`
- after Gitea is installed, you might want to create an admin user for testing (should otherwise be first user by default), you can use `sudo -u git GITEA_WORK_DIR=/data/git GITEA_CUSTOM/etc/gitea /data/git/bin/gitea admin create-user --username you --admin --password yourpassword --email youremail@example.com`
Please see the deployment repo for the folder structure as well as the [upstream docs](https://docs.gitea.io/en-us/) on how to configure and hack Gitea.
- Add a user and group git
- Provide SSH to root
- Setup a MySQL database `gitea` end enter the credentials into your app.ini
- Install at least git make nodejs npm openssh-server librsvg2-bin (example package names from Debian Buster)
- Run the makefile and see that Gitea is installed, you can override variables and run it like `make HOSTNAME_FQDN=localhost deployment`
- After Gitea is installed, you might want to create an admin user for testing (should otherwise be first user by default), you can use `sudo -u git GITEA_WORK_DIR=/data/git GITEA_CUSTOM/etc/gitea /data/git/bin/gitea admin create-user --username you --admin --password yourpassword --email youremail@example.com`
Please see the deployment repo for the folder structure as well as the [upstream docs](https://docs.gitea.io/en-us/) on how to configure and hack on Gitea.
Also note, that the Makefile by defaults compiles Codeberg's Gitea fork from the `codeberg-test` branch. You can override this behaviour by specifying ORIGIN and GITEA_BRANCH environment to the Makefile.
Also note that the Makefile compiles Codeberg's Gitea fork from the `codeberg-test` branch by default. You can override this behaviour by specifying `ORIGIN` and `GITEA_BRANCH` environment to the Makefile.
### Working with the gitea codebase
### Working with the Gitea codebase
Please look at [the Gitea docs](https://docs.gitea.io/en-us/hacking-on-gitea/) on how to start hacking on Gitea itself. They provide more detailed and especially up-to-date information than we could maintain in our own docs. Additionally, there's probably no need for reduncandy here 😉.
Please look at [the Gitea docs](https://docs.gitea.io/en-us/hacking-on-gitea/) on how to start hacking on Gitea itself. They provide more detailed and especially more up-to-date information than we could maintain in our own docs. Additionally, there's probably no need for redundancy here 😉.
### Raising an MR to our Gitea fork
If you fixed an issue specific to Codeberg that should not go into the upstream repo or was refused there, but fits the criteria for our own repo written above, you can file an MR to [our own fork of Gitea](https://codeberg.org/Codeberg/gitea). Make sure to point your MR to the codeberg branch and rebase to the latest commits there. Also explain, why this should go into the Codeberg repo, if not obvious.
If you fixed an issue specific to Codeberg that should not go into the upstream repo or was refused there, but fits the criteria for our own repo written above, you can file an MR to [our own fork of Gitea](https://codeberg.org/Codeberg/gitea). Make sure to point your MR to the codeberg branch and rebase to the latest commits there. Also explain why this should go into the Codeberg repo, if not obvious.
> **Warning** Please note, that the branches may be force-pushed at
> certain times to make sure the Codeberg commits are well visible and