Development workflow

All Forgejo commits are merged into the forgejo branch from which binary releases and packages are created and distributed. The development workflow is a set of conventions Forgejo developers are expected to follow to work together.

Naming conventions

  • development: forgejo
  • stable releases: vX.Y/forgejo

Cherry-picking

Gitea branches are regularly scrubbed, and changes useful to Forgejo are cherry picked.

Testing

Software is always tested with different methods which are more or less costly. Forgejo has a lot of technical debt and large portions of the codebase are very difficult to test. A reasonable effort should be made to improve the situation whenever a change is proposed.

Automated tests

They do not require manual intervention and can be run as often as necessary from the CI.

Ideally all aspects of a code can be verified with unit tests (e.g. make unit-test-coverage). Integration tests may involve third party components such as a database (e.g. make test-sqlite).

Tests that require launching a Forgejo instance are found in the end-to-end repository.

It is possible to run them on a pull request by setting the run-end-to-end-tests label. It will trigger a workflow that:

Manual tests

When the test infrastructure is lacking or the test to verify a change (such as a oneliner) is out of proportion with the effort to create and automated test (as a few days of work may be needed if this is in the web UI), the instructions to manually verify the change is good must be documented in the forgejo-manual-testing repository.

The person who wrote the instructions is expected to run them on a regular basis to ensure there are no regressions. If this is not done, the regression will always happen over time and will be discovered by end users which by far the most costly and frustrating method of testing.

This page's content is available under the CC-BY-SA-4.0 license.
Edit this page