From cd93d8561b61616c24e1624e07fb5b40aa2e9b42 Mon Sep 17 00:00:00 2001 From: Zach Winter <222839+zachwinter@noreply.gitea.com> Date: Sat, 25 Jul 2026 04:47:09 +0000 Subject: [PATCH] ci: wait for the gitea service to be ready before integration tests (#1062) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The `Integration Test` job is currently failing repo-wide, on unrelated PRs and on `main`: ``` curl: (7) Failed to connect to gitea port 3000 after 7 ms ``` It fails at the health check, before any Go test runs. Recent examples: #1056 (7/18), #1059, #1060, #1061. ### Cause The health check was a single bare curl fired as soon as `setup-go` finished — there was never a readiness wait. The job has been depending on gitea binding port 3000 within however long `checkout` + `setup-go` happened to take. Timings from the job logs, container start → curl: | run | gap | result | |---|---|---| | #1021 (2026-06-21) | 7.4s | pass | | #1056 (2026-07-18) | 6.3s | fail | | #1060 (2026-07-25) | 6.3s | fail | Two failures a week apart with an identical gap, and curl giving up in single-digit **milliseconds** with nothing listening, points at the service still starting rather than crashing. ### What I could not determine Two things landed in the same window and I can't separate them from outside: the service image bump 1.26.2 → 1.27.0 (d664c01) and the hosted runner fleet going v1.0.3 → v2.0.0 (visible in the log header). The service container's own stdout isn't exposed by the job log endpoint, so **"still running migrations" is inferred from timing, not observed.** Happy to be corrected by anyone who can see the container logs. ### Why this fix regardless The missing readiness wait is the actual bug class, independent of what shifted the timing. If the service is merely slower to boot, this fixes it permanently. If it is genuinely broken, this converts a cryptic 7ms connection refusal into an explicit 60s timeout with a clear error. Locally I verified the YAML parses and exercised both loop paths in a shell (success exits immediately; exhaustion emits `::error::` and exits 1). I can't run Gitea Actions locally, so this workflow's first real execution is the CI run on this PR — a passing `Integration Test` here is the fix demonstrating itself. --------- Co-authored-by: Zach Winter Reviewed-on: https://gitea.com/gitea/tea/pulls/1062 Reviewed-by: Lunny Xiao Co-authored-by: Zach Winter <222839+zachwinter@noreply.gitea.com> --- .gitea/workflows/test-pr.yml | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/.gitea/workflows/test-pr.yml b/.gitea/workflows/test-pr.yml index 28c521fb..bbb4bf75 100644 --- a/.gitea/workflows/test-pr.yml +++ b/.gitea/workflows/test-pr.yml @@ -45,7 +45,18 @@ jobs: - uses: actions/setup-go@v6 with: go-version-file: 'go.mod' - - run: curl --noproxy "*" http://gitea:3000/api/v1/version # verify connection to instance + - name: wait for the gitea instance to be ready + run: | + for i in $(seq 1 30); do + if curl --noproxy "*" -sf http://gitea:3000/api/v1/version; then + echo "gitea is ready after ${i} attempt(s)" + exit 0 + fi + echo "waiting for gitea, attempt ${i}/30" + sleep 2 + done + echo "::error::gitea did not become ready within 60s" + exit 1 - name: integration test run: | make integration-test