Files
gitocean/tests/integration
Mai-LapystandMathieu Fenniak ed63f06d79 Move web app manifest to a own cache-able route and add a setting to set "display": "standalone"; Closes #2638 (#5384)
This PR does three things:
- First it moves the inline web app manifest into its own route `/manifest.json`
- Secondly, it add a setting `pwa.STANDALONE` that can be set to `true` if one wants users to be allowed to "install" forgejo as an pwa into their browser. This usually means an "install app" button, which essentially just creates an shortcut to use a single-tab window for browsing the app / forgejo.
- Thirdly since we have now an extra route, it checks if someone placed a `public/manifest.json` in forgejo's custom path; if yes, it's content is served instead. This allows more customization without the need on our side to completly implement every nuance of web app manifests.

This closes issue #2638

### Tests

- I added test coverage for Go changes...
  - [x] in their respective `*_test.go` for unit tests.

### Documentation

- [x] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs/pulls/1669) to explain to Forgejo users how to use this change.

### Release notes

- [ ] I do not want this change to show in the release notes.
- [ ] I want the title to show in the release notes with a link to this pull request.
- [x] I want the content of the `release-notes/<pull request number>.md` to be be used for the release notes instead of the title.

<!--start release-notes-assistant-->

## Release notes
<!--URL:https://codeberg.org/forgejo/forgejo-->
- Features
  - [PR](https://codeberg.org/forgejo/forgejo/pulls/5384): <!--number 5384 --><!--line 0 --><!--description W2FsbG93IGZvcmdlam8gdG8gcnVuIGFzIGEgcHdhIHN0YW5kYWxvbmUgYXBwbGljYXRpb24gJiBvdmVycmlkZSBvZiB0aGUgd2ViYXBwIG1hbmlmZXN0Lmpzb24gdmlhIHRoZSBhIGN1c3RvbSBmaWxlIGluIGBwdWJsaWMvbWFuaWZlc3QuanNvbmBdKGh0dHBzOi8vY29kZWJlcmcub3JnL2Zvcmdlam8vZm9yZ2Vqby9wdWxscy81Mzg0KQ==-->[allow forgejo to run as a pwa standalone application & override of the webapp manifest.json via the a custom file in `public/manifest.json`](https://codeberg.org/forgejo/forgejo/pulls/5384)<!--description-->
<!--end release-notes-assistant-->

Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/5384
Reviewed-by: Otto <otto@codeberg.org>
Reviewed-by: Lucas <sclu1034@noreply.codeberg.org>
Co-authored-by: Mai-Lapyst <mai-lapyst@noreply.codeberg.org>
Co-committed-by: Mai-Lapyst <mai-lapyst@noreply.codeberg.org>
2026-01-09 17:49:29 +01:00
..
2025-04-28 16:41:33 +02:00

Integration tests

Thank you for your effort to provide good software tests for Forgejo. Please also read the general testing instructions in the Forgejo contributor documentation.

This file is meant to provide specific information for the integration tests as well as some tips and tricks you should know.

Feel free to extend this file with more instructions if you feel like you have something to share!

How to run the tests?

Before running any tests, please ensure you perform a clean build:

make clean build

Integration tests can be run with make commands for the appropriate backends, namely:

make test-sqlite
make test-pgsql
make test-mysql

Run tests via local forgejo runner

If you have a forgejo runner, you can use it to run the test jobs:

Run all jobs

forgejo-runner exec -W .forgejo/workflows/testing.yml --event=pull_request

Warning: This file defines many jobs, so it will be resource-intensive and therefore not recommended.

Run single job

forgejo-runner exec -W .forgejo/workflows/testing.yml --event=pull_request -j <job_name>

You can list all job names via:

forgejo-runner exec -W .forgejo/workflows/testing.yml --event=pull_request -l

Run sqlite integration tests

Start tests

make test-sqlite

Run MySQL integration tests

Setup a MySQL database inside docker

docker run -e MYSQL_DATABASE=test -e MYSQL_ALLOW_EMPTY_PASSWORD=yes -p 3306:3306 --rm --name mysql mysql:latest #(Ctrl-c to stop the database)

Start tests based on the database container

TEST_MYSQL_HOST=localhost:3306 TEST_MYSQL_DBNAME=test?multiStatements=true TEST_MYSQL_USERNAME=root TEST_MYSQL_PASSWORD='' make test-mysql

Run pgsql integration tests

Setup a pgsql database inside docker

docker run -e "POSTGRES_DB=test" -e POSTGRES_PASSWORD=postgres -e POSTGRESQL_FSYNC=off -e POSTGRESQL_EXTRA_FLAGS="-c full_page_writes=off" -p 5432:5432 --rm --name pgsql data.forgejo.org/oci/bitnami/postgresql:16 #(Ctrl-c to stop)

Setup a S3 server inside docker

docker run -e MINIO_ROOT_USER=123456 -e MINIO_ROOT_PASSWORD=12345678 -p 9000:9000 --rm --name minio data.forgejo.org/oci/bitnami/minio:2024.8.17 #(Ctrl-c to stop)

Start tests based on the database container

TEST_PGSQL_HOST=localhost:5432 TEST_PGSQL_DBNAME=test TEST_PGSQL_USERNAME=postgres TEST_PGSQL_PASSWORD=postgres TEST_S3_HOST=localhost:9000 make 'test-pgsql#Test'

Running individual tests

Example command to run GPG test:

For SQLite:

make test-sqlite#GPG

For other databases (replace mysql to pgsql):

TEST_MYSQL_HOST=localhost:1433 TEST_MYSQL_DBNAME=test TEST_MYSQL_USERNAME=sa TEST_MYSQL_PASSWORD=MwantsaSecurePassword1 make test-mysql#GPG

Setting timeouts for declaring long-tests and long-flushes

We appreciate that some testing machines may not be very powerful and the default timeouts for declaring a slow test or a slow clean-up flush may not be appropriate.

You can either:

  • Within the test ini file set the following section:
[integration-tests]
SLOW_TEST = 10s ; 10s is the default value
SLOW_FLUSH = 5S ; 5s is the default value
  • Set the following environment variables:
GITEA_SLOW_TEST_TIME="10s" GITEA_SLOW_FLUSH_TIME="5s" make test-sqlite

Tips and tricks

If you know noteworthy tests that can act as an inspiration for new tests, please add some details here.