Enforce Ubuntu runner policy

This commit is contained in:
MrSphay
2026-05-16 05:02:42 +02:00
parent a4245a1563
commit 2534640e54
11 changed files with 88 additions and 21 deletions

View File

@@ -32,6 +32,8 @@ If local changes exist, do not overwrite them. Fetch or report the blocker befor
Conserve context tokens while inspecting: start with targeted searches and file lists, then read only files that affect the baseline decision. Do not load generated folders, dependency folders, build outputs, or full logs unless they are directly relevant.
Treat `global-runner-1`, `global-runner-2`, and `global-runner-3` as the only supported build runners. Project builds, tests, audits, package jobs, installers, dependency setup, and releases must run on Gitea Ubuntu runners with `ubuntu-latest`, `ubuntu-24.04`, or `ubuntu-22.04`, not on the user's local machine. If tooling looks Windows-specific, use an open-source Linux-compatible workaround instead of adding a Windows runner.
Identify:
- repository name,
@@ -173,6 +175,8 @@ build
upload artifacts
```
Use only the supported Gitea Ubuntu runner labels. Do not add Windows, macOS, self-hosted local-machine, or undocumented runner labels.
Only publish artifacts to a package registry when the artifact names and credentials are known. `actions/upload-artifact` creates a workflow-run artifact, not a Gitea Package Registry package. If users need a package/download entry, add a separate generic package upload step with `REGISTRY_TOKEN`, copy artifacts to URL-safe filenames before upload, and verify the final package URL after the workflow succeeds.
Keep Codex kit files tracked in the source repository when they help agents, but exclude them from user-facing release, package, installer, archive, and GitHub/Gitea upload artifacts unless the user explicitly wants repository-maintenance files shipped. Typical excluded paths are `AGENTS.md`, `.codex/`, `blueprint.md`, `blueprint.json`, template workflow files, and `docs/agent-handoff.md`.
@@ -193,8 +197,8 @@ When the setup reveals real follow-up work that is outside the current scope or
Before final response:
- run formatting or validation if available,
- run the cheapest reliable verification command,
- run lightweight local validation if available and it does not install dependencies or create build artifacts,
- run the cheapest reliable project verification command through Gitea Actions on a supported Ubuntu runner,
- check `git diff --check`,
- if using Gitea Actions, poll the pushed workflow run until it reaches a terminal state; for private Gitea repositories on `https://git.wilkensxl.de`, use a locally set `GITEA_TOKEN` for read-only API status checks when available,
- if the pushed workflow fails or is cancelled, inspect the failing job/logs, fix in scope, push again, and repeat the workflow check loop; fixing and pushing is not a stopping point,