build(linux): add AppImage update information

[snowyukitty]

Configure Linux AppImage release jobs to embed release-independent, architecture-specific zsync update information. Verify the single generated sidecar — its exact name for this version, that the pattern the AppImage carries still matches it, and its .upd_info section — before uploading it to the current draft release with rerunnable clobber behavior.

Tests: this workflow is on: push: tags: v*.*.*, so it was not executed. The arch-mapping and sidecar filename checks were copied into a local shell script with the GitHub-provided values, $GITHUB_ENV and the bundle directory stubbed, and exercised over eight cases: both arch mappings, a rejected unknown arch, a sidecar named for the version under build passing both checks, a sidecar from a later version still matched by the embedded pattern, a wrong-version bundle still refused by the exact check, the aarch64 pattern refusing an amd64 name, and a foreign filename refused. All eight behave as described, and publish.yml still parses (yaml.safe_load), on push tags v*.*.*.

Not covered by those checks: the readelf --string-dump=.upd_info readback needs a real AppImage, so only a tagged release exercises it.

Disclosure: This contribution was prepared with OpenAI Codex assistance.

[CLAassistant]

All committers have signed the CLA.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Team

Run ID: c422283a-2bc0-45b3-958e-7ec9caac7600

📥 Commits

Reviewing files that changed from the base of the PR and between 51558e8 and 6dbc7ec.

📒 Files selected for processing (1)

• .github/workflows/publish.yml

Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review.

---

📝 Walkthrough

Walkthrough

Changes

The publish workflow configures Linux AppImage update metadata. It validates the zsync sidecar and embedded .upd_info, then uploads the verified sidecar.

Linux AppImage update publishing

Layer / File(s)	Summary
Configure and validate AppImage updates .github/workflows/publish.yml	The workflow maps matrix architectures, exports LDAI_UPDATE_INFORMATION, validates the generated zsync sidecar and embedded .upd_info, and uploads the sidecar with --clobber.

Suggested reviewers: tonyantony300

Merge Risk: ⚪ Minimal · up to 6dbc7

Linux AppImage releases now publish architecture-specific zsync sidecars with release-independent update metadata, allowing installed AppImages to locate later release sidecars. The workflow validates the metadata and artifact naming before upload, with no remaining merge-blocking risk.

🚥 Pre-merge checks | ✅ 1

✅ Passed checks (1 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0…

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[tonyantony300]

Hi @snowyukitty, can you please sign the CLA

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

.github/workflows/publish.yml (1)

293-309: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

Use a release-independent zsync filename pattern.

Because the gh-releases-zsync field matches release asset names, the version-specific DashBeam_${VERSION}_${APPIMAGE_RELEASE_ARCH}.AppImage.zsync value can prevent older AppImages from finding the sidecar in a newer latest release. Use DashBeam_*_${APPIMAGE_RELEASE_ARCH}.AppImage.zsync. Update the validation step so basename "$SIDECAR" uses pattern matching instead of exact equality.

Source: MCP tools

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Team

Run ID: 2c7d96ba-b2ac-4989-a832-4f43f6b197b0

📥 Commits

Reviewing files that changed from the base of the PR and between 942d957 and 51558e8.

📒 Files selected for processing (1)

• .github/workflows/publish.yml

Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review.

[snowyukitty]

CLA signed. I also brought the branch up to current main (51558e8); the change itself is unchanged at 1 file, +50/-0.

[snowyukitty]

The CodeRabbit finding on the gh-releases-zsync filename is right, and it defeated the whole point of the change. Fixed in 6dbc7ec; the pull request is 1 file, +70/-0 against main.

Why it mattered. The embedded filename is matched against the assets of whichever release is latest at the moment an installed AppImage checks for an update — not against the release it shipped from. The v0.7.1 assets are named DashBeam_0.7.1_amd64.AppImage, so a 0.7.1 AppImage carrying …|latest|DashBeam_0.7.1_amd64.AppImage.zsync would resolve latest to v0.7.2 and find only DashBeam_0.7.2_amd64.AppImage.zsync there. No match, no update — in exactly the case the field exists for. It would have looked correct in CI on the release that produced it and only failed on the next one.

The fix. The filename field takes * as a wildcard (AppImageSpec, update information), so the embedded value is now DashBeam_*_${APPIMAGE_RELEASE_ARCH}.AppImage.zsync. The arch suffix stays literal, so an amd64 AppImage cannot match the aarch64 sidecar.

The validation. I kept the exact check rather than loosening it to the pattern. APPIMAGE_EXPECTED_SIDECAR is built from $VERSION alongside the update information, so a bundle named for the wrong version is still refused; a second check then asserts the sidecar is matched by the pattern the AppImage actually carries. Those are different invariants now — the first says the build produced what this run intended, the second says a future release can still find it — and only the second one is new. The .upd_info readback is unchanged and still compares byte-for-byte against LDAI_UPDATE_INFORMATION.

Verification. publish.yml is on: push: tags: v*.*.*, so the workflow itself was never executed here. I copied the arch-mapping block and the sidecar filename checks into a shell harness, with the GitHub-provided values, $GITHUB_ENV and the bundle directory stubbed — the AppImage and its sidecar are empty placeholder files, so it exercises the naming and counting logic and nothing else. The cases: both arch mappings, a rejected unknown arch, a sidecar named for the version under build passing both checks, a sidecar from a later version still matched by the embedded pattern (the case that was broken), a wrong-version bundle still refused by the exact check, the aarch64 pattern refusing an amd64 name, and a foreign filename refused. Every case behaves as described.

What that does not cover: the readelf --string-dump=.upd_info readback needs a real AppImage, so it is unexercised — it is also unchanged, and it still compares byte-for-byte against LDAI_UPDATE_INFORMATION, which is now the pattern. publish.yml still parses as YAML.