build(linux): add AppImage update information - #311

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

No actionable comments were generated in the recent review. 🎉

Priority: ⬇️ Low

Change: Feature

Merge Risk: ⚪ Minimal · up to ba16a

The update metadata no longer confines newly built AppImages to their original version’s sidecar. No actionable merge-blocking issue remains after normal release checks.

Pre-merge checks | 1

✅ Passed checks (1 passed)

Check name	Status	Explanation
Docstring Coverage		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…

---

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.

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

Hi @snowyukitty, can you please sign the CLA

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

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.