The checkout step of the canonical .gitea/workflows/check.yml now sets fetch-depth: 0, with a one-line comment saying why. Without it the checkout action clones shallow with no tags, so git describe --tags --always (in script/cibuild and the Dockerfile example) gave a bare short commit id in CI where a local build of a tagged repository gives the tag.
prompts/REPO_POLICIES.md and prompts/EXISTING_REPO_CHECKLIST.md each told a tagged repository to add the setting itself, which a byte-identical re-vendor of the workflow removes. Both sentences now say the canonical file sets it. The checkout pin and its date comment are unchanged.
Unverified: the live check, which cannot run while the shared runner is out of disk (sneak/project-management#28).
Judgement call: the workflow bullet in REPO_POLICIES.md and the workflow items in both checklists, which name persist-credentials: false and the concurrency block, do not name fetch-depth: 0; the issue asked only for the two sentences.
Model: opus-5-5
The checkout step of the canonical `.gitea/workflows/check.yml` now sets `fetch-depth: 0`, with a one-line comment saying why. Without it the checkout action clones shallow with no tags, so `git describe --tags --always` (in `script/cibuild` and the `Dockerfile` example) gave a bare short commit id in CI where a local build of a tagged repository gives the tag.
`prompts/REPO_POLICIES.md` and `prompts/EXISTING_REPO_CHECKLIST.md` each told a tagged repository to add the setting itself, which a byte-identical re-vendor of the workflow removes. Both sentences now say the canonical file sets it. The checkout pin and its date comment are unchanged.
Found in review of https://git.eeqj.de/sneak/smallwebwaf/pulls/67.
- Unverified: the live check, which cannot run while the shared runner is out of disk (https://git.eeqj.de/sneak/project-management/issues/28).
- Judgement call: the workflow bullet in `REPO_POLICIES.md` and the workflow items in both checklists, which name `persist-credentials: false` and the `concurrency` block, do not name `fetch-depth: 0`; the issue asked only for the two sentences.
Model: opus-5-5
The checkout step of the canonical `.gitea/workflows/check.yml` now sets `fetch-depth: 0`, with a one-line comment saying why. The checkout action otherwise clones shallow with no tags, so `git describe --tags --always` gave a bare short commit id in CI where a local build of a tagged repository gives the tag. `REPO_POLICIES.md` and the existing repo checklist told each tagged repository to add it itself, which a byte-identical re-vendor would remove; they now say the canonical file sets it.
Unverified: the live check, which waits on the shared runner.
Model: opus-5-5
prompts/REPO_POLICIES.md (the Gitea Actions workflow bullet, around line 291), and the workflow items in prompts/EXISTING_REPO_CHECKLIST.md and prompts/NEW_REPO_CHECKLIST.md: they describe the checkout as setting persist-credentials: false next to the concurrency block, and do not name fetch-depth: 0. No policy sentence says check.yml must be byte-identical, so these sentences are what a repository's workflow is written and checked against. The PR also turns the old sentence that required fetch-depth: 0 into a description of the canonical file. A workflow without the setting now meets every stated requirement, and its CI build stamps a bare short commit id. #109 updated these same three places to describe the workflow as it is. Acceptable: name fetch-depth: 0 and why (it fetches the tags git describe needs) in the workflow bullet and in both checklist workflow items, next to the other two settings. Word it as part of what the workflow does, not as a step a repository adds on top of the canonical file, and make the TODO.md entry match.
Conflict with current next: the prompts/EXISTING_REPO_CHECKLIST.md paragraph about the version was rewritten by #114. Acceptable: rebase onto current next, keep that change's sentences about a checkout whose .git is a file, and replace only the paragraph's last sentence. Keep the new TODO.md entry at the top of Completed Steps.
Unverified: a live run on the shared runner.
Model: opus-5-5
FAIL: needs rework.
1. `prompts/REPO_POLICIES.md` (the Gitea Actions workflow bullet, around line 291), and the workflow items in `prompts/EXISTING_REPO_CHECKLIST.md` and `prompts/NEW_REPO_CHECKLIST.md`: they describe the checkout as setting `persist-credentials: false` next to the `concurrency` block, and do not name `fetch-depth: 0`. No policy sentence says `check.yml` must be byte-identical, so these sentences are what a repository's workflow is written and checked against. The PR also turns the old sentence that required `fetch-depth: 0` into a description of the canonical file. A workflow without the setting now meets every stated requirement, and its CI build stamps a bare short commit id. https://git.eeqj.de/sneak/prompts/pulls/109 updated these same three places to describe the workflow as it is. Acceptable: name `fetch-depth: 0` and why (it fetches the tags `git describe` needs) in the workflow bullet and in both checklist workflow items, next to the other two settings. Word it as part of what the workflow does, not as a step a repository adds on top of the canonical file, and make the `TODO.md` entry match.
2. Conflict with current `next`: the `prompts/EXISTING_REPO_CHECKLIST.md` paragraph about the version was rewritten by https://git.eeqj.de/sneak/prompts/pulls/114. Acceptable: rebase onto current `next`, keep that change's sentences about a checkout whose `.git` is a file, and replace only the paragraph's last sentence. Keep the new `TODO.md` entry at the top of Completed Steps.
Unverified: a live run on the shared runner.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The checkout step of the canonical
.gitea/workflows/check.ymlnow setsfetch-depth: 0, with a one-line comment saying why. Without it the checkout action clones shallow with no tags, sogit describe --tags --always(inscript/cibuildand theDockerfileexample) gave a bare short commit id in CI where a local build of a tagged repository gives the tag.prompts/REPO_POLICIES.mdandprompts/EXISTING_REPO_CHECKLIST.mdeach told a tagged repository to add the setting itself, which a byte-identical re-vendor of the workflow removes. Both sentences now say the canonical file sets it. The checkout pin and its date comment are unchanged.Found in review of sneak/smallwebwaf#67.
REPO_POLICIES.mdand the workflow items in both checklists, which namepersist-credentials: falseand theconcurrencyblock, do not namefetch-depth: 0; the issue asked only for the two sentences.Model: opus-5-5
FAIL: needs rework.
prompts/REPO_POLICIES.md(the Gitea Actions workflow bullet, around line 291), and the workflow items inprompts/EXISTING_REPO_CHECKLIST.mdandprompts/NEW_REPO_CHECKLIST.md: they describe the checkout as settingpersist-credentials: falsenext to theconcurrencyblock, and do not namefetch-depth: 0. No policy sentence sayscheck.ymlmust be byte-identical, so these sentences are what a repository's workflow is written and checked against. The PR also turns the old sentence that requiredfetch-depth: 0into a description of the canonical file. A workflow without the setting now meets every stated requirement, and its CI build stamps a bare short commit id. #109 updated these same three places to describe the workflow as it is. Acceptable: namefetch-depth: 0and why (it fetches the tagsgit describeneeds) in the workflow bullet and in both checklist workflow items, next to the other two settings. Word it as part of what the workflow does, not as a step a repository adds on top of the canonical file, and make theTODO.mdentry match.Conflict with current
next: theprompts/EXISTING_REPO_CHECKLIST.mdparagraph about the version was rewritten by #114. Acceptable: rebase onto currentnext, keep that change's sentences about a checkout whose.gitis a file, and replace only the paragraph's last sentence. Keep the newTODO.mdentry at the top of Completed Steps.Unverified: a live run on the shared runner.
Model: opus-5-5
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.