Publish ezdbbackup through the EZ Game Host APT repository - #1
Conversation
📝 WalkthroughWalkthroughThe release pipeline now builds and verifies Debian packages, publishes selected release assets, adds authenticated APT publication, and documents Debian and Ubuntu installation. ChangesAPT release infrastructure
Estimated code review effort: 3 (Moderate) | ~25 minutes Sequence Diagram(s)sequenceDiagram
participant apt-publish
participant GitHubRelease
participant APTPublishingAction
apt-publish->>GitHubRelease: download and verify release artifacts
apt-publish->>APTPublishingAction: provide verified amd64 and arm64 packages
APTPublishingAction->>GitHubRelease: attach or verify package assets
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/release.yml:
- Around line 150-155: Broaden the release-version validation in
scripts/package-release.sh, then validate the version without the leading v
using dpkg --validate-version. In .github/workflows/release.yml:150-155, replace
the restrictive regex check with dpkg --validate-version "${version}"
>/dev/null. Update test/workflow/release_test.go:238-249 to expect the dpkg
validation and cover versions containing +, with no direct change required at
the workflow site beyond the validation replacement.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: ecf86a01-30df-45df-9a3c-a5b64e537db7
📒 Files selected for processing (9)
.github/workflows/release.ymlREADME.mddocs/superpowers/plans/2026-08-10-apt-repository-infrastructure.mddocs/superpowers/specs/2026-08-10-apt-repository-infrastructure-design.mdpackaging/debian/changelog.templatepackaging/debian/copyrightscripts/package-release.shtest/workflow/package_release_test.gotest/workflow/release_test.go
| version="${GITHUB_REF_NAME#v}" | ||
| [[ "${version}" =~ ^[0-9A-Za-z][0-9A-Za-z._-]*$ ]] | ||
| amd64="dist/ezdbbackup_${version}_amd64.deb" | ||
| arm64="dist/ezdbbackup_${version}_arm64.deb" | ||
| [[ -f "${amd64}" && ! -L "${amd64}" ]] | ||
| [[ -f "${arm64}" && ! -L "${arm64}" ]] |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
version='1.2.3+build.1'
dpkg --validate-version "${version}"
git check-ref-format "refs/tags/v${version}"
rg -n -C 2 'validate-version|0-9A-Za-z._-' \
scripts/package-release.sh .github/workflows/release.yml test/workflow/release_test.goRepository: ezgamehost/ezdbbackup
Length of output: 201
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- scripts/package-release.sh ---'
rg -n -C 5 'validate-version|version|dpkg' scripts/package-release.sh || true
printf '%s\n' '--- workflow target ---'
sed -n '135,165p' .github/workflows/release.yml
printf '%s\n' '--- test target ---'
sed -n '220,265p' test/workflow/release_test.go
printf '%s\n' '--- related version checks ---'
rg -n -C 3 'validate-version|GITHUB_REF_NAME|package-release|0-9A-Za-z|apt-publish' \
scripts .github/workflows test/workflow || true
printf '%s\n' '--- tracked files ---'
git ls-files scripts/package-release.sh .github/workflows/release.yml test/workflow/release_test.goRepository: ezgamehost/ezdbbackup
Length of output: 19671
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '%s\n' '--- package-release version tests ---'
rg -n -C 8 'GITHUB_REF_NAME|unsupported release tag|valid Debian version|invalid|plus|\+' \
test/workflow/package_release_test.go scripts/package-release.sh
printf '%s\n' '--- release trigger and job dependencies ---'
sed -n '1,80p' .github/workflows/release.yml
sed -n '80,145p' .github/workflows/release.yml
printf '%s\n' '--- repository documentation for release tags ---'
rg -n -C 3 'release tag|version tag|semantic|SemVer|tag.*v[0-9]|\+build|Debian version' \
README.md CONTRIBUTING.md .github scripts test 2>/dev/null || true
printf '%s\n' '--- available local version tools ---'
command -v dpkg || true
command -v dpkg-deb || true
command -v git || true
git check-ref-format 'refs/tags/v1.2.3+build.1'Repository: ezgamehost/ezdbbackup
Length of output: 20133
🌐 Web query:
Debian Policy version strings plus sign dpkg --validate-version official documentation
💡 Result:
In the Debian package management system, the plus sign (+) is a valid character in version strings and is explicitly allowed by official Debian Policy [1][2][3]. Version Format The format for a Debian package version string is: [epoch:]upstream_version[-debian_revision] [1][2][4]. The plus sign (+) is permitted in both the upstream_version and the debian_revision components [1][2]. Specifically, the upstream_version may contain alphanumerics and the characters. + -: ~ (full stop, plus, hyphen, colon, tilde) [2][3]. The debian_revision may contain alphanumerics and the characters +. ~ (plus, full stop, tilde) [1][2]. Note that hyphens are only allowed in the debian_revision or if a debian_revision is present, as the package management system uses the last hyphen to separate the upstream version from the revision [1][2]. Validation You can validate version strings using the dpkg command-line tool [5][6]. The --validate-thing command, introduced in dpkg 1.18.16, allows for syntax checking [5][7]. To validate a version string, use: dpkg --validate-version <version_string> The command will return an exit code of 0 if the version string is valid, 1 if it is invalid but might be accepted in lax contexts, and 2 if the string is entirely invalid [5][6].
Citations:
- 1: https://www.debian.org/doc/debian-policy/ch-controlfields.html
- 2: https://manpages.debian.org/unstable/dpkg-dev/deb-version.7.en.html
- 3: https://man.archlinux.org/man/deb-version.7.en.txt
- 4: http://www.fifi.org/doc/debian-policy/policy.html/ch-versions.html
- 5: https://man.archlinux.org/man/dpkg.1.en.txt
- 6: https://man.archlinux.org/man/dpkg.1.en.raw
- 7: https://manpages.ubuntu.com/manpages/bionic/man1/dpkg.1.html
🌐 Web query:
Git check-ref-format tag name plus sign official documentation
💡 Result:
In Git's official documentation, the command git check-ref-format is used to verify if a reference name is well-formed, but it does not specifically restrict or define the use of a plus sign (+) within a tag name itself [1][2]. The confusion regarding the plus sign often arises because it has a specific, different meaning when used in the context of refspecs (such as in git push or git fetch commands) [3][4][5]. In those contexts, a leading plus sign (+) is an optional prefix that forces an update, overriding the fast-forward requirement [4][6][5]. Regarding reference naming rules, git check-ref-format enforces the following constraints on all reference names (including tags): - They must contain at least one slash (/) (e.g., tags/my-tag), unless the --allow-onelevel option is used [1][2]. - They cannot contain a space, tilde (~), caret (^), colon (:), question mark (?), asterisk (*), open bracket ([), or control characters [1][2]. - They cannot end with a slash, dot, or the sequence.lock [2]. - They cannot contain consecutive dots (..) [2]. If you are concerned about whether a specific tag name containing a plus sign is valid, you can test it directly using the command: git check-ref-format refs/tags/ If the command exits with a status of 0, the name is valid [1][2].
Citations:
- 1: https://git-scm.org/docs/git-check-ref-format
- 2: https://kernel.googlesource.com/pub/scm/git/git-htmldocs.git/+/e22a3d246ff5995d58a2423471f88e3b0806826e/git-check-ref-format.html
- 3: https://cdn.kernel.org/pub/software/scm/git/docs/git-push.html
- 4: https://git-scm.com/book/en/v2/Git-Internals-The-Refspec
- 5: https://git.github.io/htmldocs/git-fetch.html
- 6: https://git-scm.com/docs/git-push/2.44.0
Allow valid Debian versions in every release gate.
v1.2.3+build.1 is valid for Git tags and Debian versions, but scripts/package-release.sh rejects it before packaging. The workflow repeats the same restrictive check. The failure occurs in static-build, before publish or apt-publish.
- Broaden the pre-check in
scripts/package-release.sh, then validate${version#v}withdpkg --validate-version. - Replace the workflow check with
dpkg --validate-version "${version}" >/dev/null. - Update
test/workflow/release_test.goto match and cover+.
📍 Affects 2 files
.github/workflows/release.yml#L150-L155(this comment)test/workflow/release_test.go#L238-L249
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/release.yml around lines 150 - 155, Broaden the
release-version validation in scripts/package-release.sh, then validate the
version without the leading v using dpkg --validate-version. In
.github/workflows/release.yml:150-155, replace the restrictive regex check with
dpkg --validate-version "${version}" >/dev/null. Update
test/workflow/release_test.go:238-249 to expect the dpkg validation and cover
versions containing +, with no direct change required at the workflow site
beyond the validation replacement.
1 participant
Summary
Verification
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Tests