mirror of
https://codeberg.org/davrot/forgejo.git
synced 2025-07-10 16:00:04 +02:00

Automerge can be ignored when the following race happens: * Conflict check is happening on a repository and `pr.Status = issues_model.PullRequestStatusChecking` for all open pull requests (this happens every time a pull request is merged). * While the conflict check is ongoing, an event (Forgejo Actions being successful for instance) happens and and `StartPRCheckAndAutoMerge*` is called. * Because `pr.CanAutoMerge()` is false, the pull request is not selected and not added to the automerge queue. * When the conflict check completes and `pr.CanAutoMerge()` becomes true, there no longer is a task in the auto merge queue and the auto merge does not happen. This is fixed by adding a task to the auto merge queue when the conflict check for a pull request completes. This is done when the mutx protecting the conflict check task is released to prevent a deadlock when a synchronous queues are used in the following situation: * the conflict check task finds the pull request is mergeable * it schedules the auto merge tasks that finds it must be merged * merging concludes with scheduling a conflict check task Avoid an extra loop where a conflict check task queues an auto merge task that will schedule a conflict check task if the pull request can be merged. The auto merge row is removed from the database before merging. It would otherwise be removed after the merge commit is received via the git hook which happens asynchronously and can lead to a race. StartPRCheckAndAutoMerge is modified to re-use HeadCommitID when available, such as when called after a pull request conflict check. --- A note on tests: they cover the new behavior, i.e. automerge being triggered by a successful conflict check. This is also on the critical paths for every test that involve creating, merging or updating a pull request. - `tests/integration/git_test.go` - `tests/integration/actions_commit_status_test.go` - `tests/integration/api_helper_for_declarative_test.go` - `tests/integration/patch_status_test.go` - `tests/integration/pull_merge_test.go` The [missing fixture file](https://codeberg.org/forgejo/forgejo/pulls/8189/files#diff-b86fdd79108b3ba3cb2e56ffcfd1be2a7b32f46c) for the auto merge table can be verified to be necessary simply by removing it an observing that the integration tests fail. The [scheduling of the auto merge task](https://codeberg.org/forgejo/forgejo/pulls/8189/files#diff-9489262e93967f6bb2db41837f37c06f4e70d978) in `testPR` can be verified to be required by moving it in the `testPRProtected` function and observing that the tests hang forever because of the deadlock. ## Checklist The [contributor guide](https://forgejo.org/docs/next/contributor/) contains information that will be helpful to first time contributors. There also are a few [conditions for merging Pull Requests in Forgejo repositories](https://codeberg.org/forgejo/governance/src/branch/main/PullRequestsAgreement.md). You are also welcome to join the [Forgejo development chatroom](https://matrix.to/#/#forgejo-development:matrix.org). ### Tests - I added test coverage for Go changes... - [ ] in their respective `*_test.go` for unit tests. - [x] in the `tests/integration` directory if it involves interactions with a live Forgejo server. - I added test coverage for JavaScript changes... - [ ] in `web_src/js/*.test.js` if it can be unit tested. - [ ] in `tests/e2e/*.test.e2e.js` if it requires interactions with a live Forgejo server (see also the [developer guide for JavaScript testing](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/tests/e2e/README.md#end-to-end-tests)). ### Documentation - [ ] I created a pull request [to the documentation](https://codeberg.org/forgejo/docs) to explain to Forgejo users how to use this change. - [x] I did not document these changes and I do not expect someone else to do it. ### Release notes - [ ] I do not want this change to show in the release notes. - [x] I want the title to show in the release notes with a link to this pull request. - [ ] 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--> - Bug fixes - [PR](https://codeberg.org/forgejo/forgejo/pulls/8189): <!--number 8189 --><!--line 0 --><!--description ZG8gbm90IGlnbm9yZSBhdXRvbWVyZ2Ugd2hpbGUgYSBQUiBpcyBjaGVja2luZyBmb3IgY29uZmxpY3Rz-->do not ignore automerge while a PR is checking for conflicts<!--description--> <!--end release-notes-assistant--> Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/8189 Reviewed-by: Michael Kriese <michael.kriese@gmx.de> Reviewed-by: Lucas <sclu1034@noreply.codeberg.org> Co-authored-by: Earl Warren <contact@earl-warren.org> Co-committed-by: Earl Warren <contact@earl-warren.org>
122 lines
3.3 KiB
Markdown
122 lines
3.3 KiB
Markdown
# 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](https://forgejo.org/docs/next/contributor/testing/).
|
|
|
|
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:
|
|
```shell
|
|
make test-sqlite
|
|
make test-pgsql
|
|
make test-mysql
|
|
```
|
|
|
|
|
|
### Run tests via local forgejo runner
|
|
|
|
If you have a [forgejo runner](https://code.forgejo.org/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
|
|
|
|
```SHELL
|
|
forgejo-runner exec -W .forgejo/workflows/testing.yml --event=pull_request -j <job_name>
|
|
```
|
|
|
|
You can list all job names via:
|
|
|
|
```SHELL
|
|
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 POSTGRESQL_FSYNC=off 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 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#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:
|
|
|
|
```ini
|
|
[integration-tests]
|
|
SLOW_TEST = 10s ; 10s is the default value
|
|
SLOW_FLUSH = 5S ; 5s is the default value
|
|
```
|
|
|
|
* Set the following environment variables:
|
|
|
|
```bash
|
|
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.
|