mi/werkator
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
Files
follow-up-builds
werkator/docs/prs/2026-09-04-PR#21-gitea-default-clone-url.md
T
miClaude Opus 5mhoennig
 092183ca30 Clone the watched repository from Gitea by default (#21) 
The repository moved to git.javagil.de, but repo-init still defaulted to
the GitHub mirror, which is no longer updated.
A freshly cloned instance therefore watched a stale main.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: mhoennig <michael@hoennig.de>
Reviewed-on: #21
2026-09-04 13:33:08 +02:00

1.8 KiB
Raw Permalink Blame History

WARNING: This document describes only the change applied in this PR. It may already be outdated once the next PR is merged. Historic PR-documentation is not maintained along with new PRs — treat it as a snapshot, not as current documentation.

The Problem

The repository's home is https://git.javagil.de/mi/werkator.git since the move to the own Gitea instance, but tools/remote still defaulted WERKATOR_REPO_URL to the GitHub mirror.

The mih09 production instance was cloned from that mirror and consequently watched a main that nobody pushes to any more: it kept reporting the last GitHub state as green while three merged pull requests sat unbuilt on the real main. The failure that started this — a flaky test already fixed on Gitea's main — could not be re-verified live, because the instance had no way to see the fix.

Non-Goals

  • The existing clone on mih09 is not touched by this change; its remote was repointed by hand (git remote set-url), and repo-init skips an existing clone.
  • The generic placeholder URLs in docs/deployment.md stay as they are — they describe cloning any watched repository, not werkator's own.
  • No decision about mirroring to GitHub; the mirror simply stops being the source an instance builds from.

The Solution

REPO_URL in tools/remote defaults to the Gitea URL, and the usage comment says so.

The value stays overridable via WERKATOR_REPO_URL in the instance's env file, so an installation that deliberately watches a different remote is unaffected. Anonymous HTTPS works against Gitea exactly as it did against GitHub, so no deploy key or token is involved.

Note that pull requests opened via AGit-Flow create no branch in Gitea, so an instance watching this remote sees main only — branch builds require pushing real branches.

Reference in New Issue View Git Blame Copy Permalink