Files
gitocean/tests/integration
GustedandEarl Warren 62ec469394 feat: replace go-rpmutils library with our own (#7953)
- While doing cross-compiling of Forgejo (with CGO enabled) it was noticed that besides compiling sqlite3, github.com/DataDog/zstd (a CGO wrapper around the reference zstd library) took a long time to compile. Upon investigating why this library was included in the first place I concluded that this library is not even used and compiling this package is a waste of time and CPU cycles.
- https://github.com/sassoftware/go-rpmutils is the library that uses the CGO zstd library, and would use it the pure Go variant (https://github.com/klauspost/compress/zstd) if CGO is enabled (which is the default). It uses zstd to uncompress the payload of a RPM packages. This is a operation that Forgejo does not use in the slightest, hence being unused code.
- It is not possible to force compiling the pure Go variant if CGO is enabled. Therefore forking and removing this code is the only option to avoid compiling the zstd C library. The changes made to the fork can be seen here: https://code.forgejo.org/forgejo/go-rpmutils/compare/2660c86d578cd2a5366fe5bda488e37f9ab1b11a...v1.0.0
- Via [actiongraph](https://github.com/icio/actiongraph) you can precisely see where the Go compiler is spending time, on a beefy machine the compilation takes of the zstd C library takes ~40s. For reference compiling the sqlite3 C library takes ~50s.
- The forgejo binary (build via `make backend`) reduced its size by 835776 bytes (0.8 MiB).

TL;DR forked library to remove unused code to avoid Go spending a considerable amount of time compiling the reference zstd library that in the end is never used.

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

## Release notes
<!--URL:https://codeberg.org/forgejo/forgejo-->
- Features
  - [PR](https://codeberg.org/forgejo/forgejo/pulls/7953): <!--number 7953 --><!--line 0 --><!--description cmVwbGFjZSBnby1ycG11dGlscyBsaWJyYXJ5IHdpdGggb3VyIG93bg==-->replace go-rpmutils library with our own<!--description-->
<!--end release-notes-assistant-->

Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/7953
Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org>
Co-authored-by: Gusted <postmaster@gusted.xyz>
Co-committed-by: Gusted <postmaster@gusted.xyz>
2025-05-25 12:30:04 +02:00
..
2025-04-28 16:41:33 +02:00
2024-03-22 07:11:52 +01: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 -p 5432:5432 --rm --name pgsql postgres:latest #(Ctrl-c to stop the database)

Start tests based on the database container

TEST_STORAGE_TYPE=local TEST_PGSQL_HOST=localhost:5432 TEST_PGSQL_DBNAME=test TEST_PGSQL_USERNAME=postgres TEST_PGSQL_PASSWORD=postgres make test-pgsql

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.