c4269f40e3
Use the full ubuntu runner label so Gitea Actions resolves gitea/runner-images:ubuntu-22.04 instead of falling back to ubuntu:latest during test runs. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
1.9 KiB
1.9 KiB
CI build notes
2026-04-24
- Observed failure while reproducing workflow checkout locally: the
Checkout codestep rangit remote add origin ...unconditionally. In a workspace that already had anoriginremote, the job failed witherror: remote origin already exists.and exited beforedocker build. - Why this matters for act_runner: self-hosted Gitea runners can reuse working directories or start from repositories that already contain Git metadata, so checkout logic must be idempotent.
- Applied fix: changed
.gitea/workflows/package.ymlto initialize Git only when needed, usegit remote set-url origin ...whenoriginalready exists, and force-clean the workspace after checking outFETCH_HEAD. - Safety improvement for remote validation: tags ending with
-testnow run the build verification path only. They skip registry login, image push,latestupdates, and the deploy webhook so act_runner can be tested without deployment side effects. - Root cause found on the real act_runner: although the runner was registered with
ubuntu:docker://gitea/runner-images:ubuntu-22.04, the workflow usedruns-on: ubuntu, and the job log showedStart image=ubuntu:latest. That default image does not include the expected toolset, which explains the remotegit: not foundfailure. - Applied fix for label selection: changed both jobs to
runs-on: "ubuntu:docker://gitea/runner-images:ubuntu-22.04"so Gitea resolves the exact runner image instead of falling back toubuntu:latest. - Current local result:
npm run lint,npm run test -- --runInBand,npm run build,docker build ..., andnpm run buildinsidegitea/runner-images:ubuntu-22.04all completed successfully after the workflow adjustment. - Non-blocking note: local Jest run reported a haste-map naming collision between
package.jsonand.next/standalone/package.json; tests still passed, and this does not affect the current image-build workflow.