EIN BLOCK, ZWEI BLOCK, DREI BLOCK, VIIIIIIIER #671
No reviewers
Labels
No labels
accepted
bug
dependencies
docker
documentation
duplicate
enhancement
github-actions
github_actions
good first issue
gradle
hacktoberfest-accepted
help wanted
invalid
javascript
not-an-issue
npm
question
rejected
wontfix
Working on it
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
Griefed/ServerPackCreator!671
Loading…
Reference in a new issue
No description provided.
Delete branch "develop"
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?
`npx -p <name>` with no version resolves to the newest major on every run, so three of the four packages this step installs were floating. One of them moved and took the release with it: conventional-changelog-conventionalcommits@10 switched to @conventional-changelog/template, whose createLegacyWriterGuard() deliberately plants a bogus `mainTemplate` so that a pre-9 writer throws instead of silently emitting an empty changelog. semantic-release@24 depends on @semantic-release/release-notes-generator@14, which depends on conventional-changelog-writer@^8 -- a legacy writer -- so the guard fired and generateNotes died with Missing helper: "conventional-changelog-conventionalcommits requires conventional-changelog-writer@9 or newer ..." Measured against @semantic-release/release-notes-generator@14.1.1, calling generateNotes directly: preset 8.0.0 renders preset 9.3.1 renders preset 10.4.0 throws the error above Preset 9 is therefore the ceiling, and upgrading semantic-release is not an escape hatch: 25.0.9 still depends on release-notes-generator ^14.1.0, hence still writer 8. release-notes-generator@15, which would bring writer 9, is beta-only. Unpin once that ships and semantic-release depends on it. Rehearsed end to end against a local bare clone of this repository standing in for origin: with the pin, generateNotes completed with zero errors over the real 229 commits since 9.0.0-alpha.5, rendering every custom section title from .releaserc.yml. changelog and git are pinned to their current majors for the same reason, not because either is currently broken. This fixes the crash only. The same run also resolved the wrong last release (8.1.2 instead of 9.0.0-alpha.5) for an unrelated reason -- see claude-docs/RELEASE-TAG-REPAIR.md. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>The 2026-08-22 release-generate.yml run failed twice over: it crashed in generateNotes, and before that it had already picked the wrong last release -- `Found git tag 8.1.2 ... on branch alpha` with 9.0.0-alpha.5 sitting right there. Neither is visible in the workflow YAML, so both go in the rule file that loads when .forgejo/** is touched. Landmine 1: semantic-release stores a release's channel in refs/notes/semantic-release, not in the tag. get-tags.js falls back to `channels = [null]` for a tag with no note, and get-last-release.js keeps a prerelease branch's tags only when their channels match the branch channel -- so on a remote with zero notes every X-alpha.N tag is invisible and only the newest non-prerelease tag survives. The Forgejo remote has 375 tags and no refs/notes/* at all, because a forge migration carries branches and tags but not notes. Also recorded: actions/checkout needs no change, since semantic-release runs fetchNotes itself -- verified against a fresh clone whose only copy of the notes was on the remote. Landmine 2: creating a release through the forge API mints a missing tag at target_commitish. 9.0.0-alpha.1 through .5 still report "target_commitish": "main", and all five tags sit on main's tip (the RELEASE: 8.1.2 commit) instead of on their own RELEASE commits. Comparing all 375 remote tags against local bounds the damage exactly: those five, plus the ghost 9.0.0-alpha.6, plus `continuous` which is supposed to move; the other 368 match byte for byte. release-build.yml is explicitly cleared -- it posts no target_commitish to Forgejo -- and how alpha.6's tag reached that commit is stated as unrecoverable rather than guessed at. RELEASE-TAG-REPAIR.md is the runbook for the honest repair Griefed chose: retarget .1-.5, delete the ghost .6 release and tag, write the channel notes. It is written to be run by hand and it was rehearsed against a local bare clone of this repository standing in for origin: broken (tags forced onto6cd6e9af3, no notes) last=8.1.2 624 commits next=9.0.0-alpha.1 repaired (retargeted, .6 deleted, notes pushed) last=9.0.0-alpha.5 229 commits next=9.0.0-alpha.6 The broken row reproduces the failing CI run down to the commit count, which is what makes this a finding rather than a theory. Also written down: the dry-run log flattens the changelog heading's markdown link and indents the bullets, which looks like a format regression and is only signale rendering multi-line output -- the written string is byte-identical in shape to existing CHANGELOG.md entries under both preset 8 and preset 9. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>`PathsConfig` resolved a source build's home from `File("").absolutePath`, which is unobservable from a test: the JVM resolves an empty path against the working directory it was *launched* with and ignores a later `user.dir` (verified — setting the property mid-process does not move `File("").absolutePath`). Taking it as a constructor parameter with that same value as the default lets a test present a different one. Behaviour-preserving: the default is the expression it replaces, and ApiProperties, the only caller, does not pass it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>Audit iteration 12, L2. The window was `substringAfter("fun main(args: Array<String>) {")` — main's body *plus every declaration below it* — so both `indexOf` calls could match text that is not main: the `pinSpcHomeDirectory` declaration, or a helper's log call. It passed for the right reason only because main happens to precede the helpers in the file; reorder them, or drop main's logging, and it would go green while asserting nothing. That is the failure class this repo has recorded twice already. Now cut by brace-matching from main's opening brace, and the extractor asserts its own boundedness so the window cannot silently run past main again. Teeth checked by mutation, which is the point of the finding: moving both claims back below main's first log statement turns the guard red with the intended message, and reverting turns it green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>Audit of the two deployment commits, run immediately after they landed. No HIGH; one MEDIUM and three LOW, all fixed here. M1 — PREFIX, SERVICE_USER and SERVICE_HOME are overridable while the unit hardcodes all three, so an override produced a successful install the unit could not start. The installer now parses User=, WorkingDirectory= and ExecStart= out of the unit and reports any disagreement. A warning, not a failure: an operator with their own edited copy is doing nothing wrong. L1 — rm -rf "${PREFIX:?}/lib" was guarded against an *unset* PREFIX, which is not the dangerous case. PREFIX=/ reached `rm -rf /lib`. PREFIX must now be absolute and at least two components deep; / and /usr are both rejected by name, verified. L2 — "one sudo prompt up front" was untrue: the timestamp lasts ~15 minutes and a cold image build plus a Gradle build outlives it. Refreshed before the privileged block, and the comment now describes what happens. L3 — the header said to run it from the repository root, which the script does not care about; repo_root comes from BASH_SOURCE. Verified rather than assumed, in the shell: cp -a merges on a re-run instead of nesting bin/bin, the exec bit survives git as 100755, and the deploy/ gitignore exception holds. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>