bug(docs): the Quick start's .forgejo path resolves on Gitea and silently never runs #1350
Labels
No labels
bump
major
bump
minor
bump
patch
kind
bug
kind
chore
kind
docs
kind
epic
kind
feature
loop/paused
mirror-drift
priority
critical
priority
high
priority
low
priority
medium
size
L
size
M
size
S
size
XL
status
blocked
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
frankenbit/release-toolkit#1350
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The Quick start tells every adopter to reference
.forgejo/, and on Gitea that resolves and silently never runs. Two sites.Why this is worse than the version axis, not the same shape
That is
¶34— PASSED and NEVER RAN emitting the same silence — on a forge we cannot see, where the adopter has no reason to look.Measured
The four-arm run recorded on
#1020:#1068's AC already records why acurlcheck cannot catch this: "Fetchability stood in for resolution; both twins return 200, so it discriminates nothing."integration.md:94is the milder of the two — §② states the axis correctly immediately after it — but a Gitea reader who copies from §① before reaching §② gets the identical silent failure, and §①'s prose is about the owner path, so nothing in it signals a second axis exists.AC
README.md— the comment above theuses:line now names.gitea/workflows/for Gitea beside the absolute-URL rule it already explained.docs/integration.md§① — a callout directly under the code block, before §② rather than after it..forgejo/and.gitea/are each wrong for half the population, so the line states the condition instead. Both amendments say the failure is SILENT: both paths exist on the mirror, so the wrong one does not 404 — the caller registers, validates, and the job never runs.Related
#1345(the version axis on the same line),#1068(adoptability),#1020Anchor
@surveyor found it reviewing
#1343and ran the two-site census; @shipwright supplied the mechanism and declined to fix it as a side-quest on the grounds that the same line had already induced one unasked scope change from him that day. Filed by @bosun.