fix/improve programs reported version + add persistent releases support

[benoit-pierre]

Version:

• fix discrepancy between filename version number and the version reported by --help: for example, ./appimagetool-823-x86_64.AppImage --help would show 177 for the version instead of 823 (177+646).
• when possible, add commit hash to the reported version: e.g. when building from a local git checkout:

▸ ./build/mkappimage-2025-12-12_151653-x86_64.AppImage --help
[…]
VERSION:
   2025-12-12_151653 - 6bb24503a3f5c0d9a6b2f7e2c644347cef0f3c46
[…]

Persistent releases:

Tweak the workflow dispatch trigger to allow generating a persistent release:

• from GitHub's website actions' tab: select the "Build All Architectures" workflow, then click on "Run workflow" and tick the "Create a non-continuous release" option before triggering the workflow.
• using the cli: gh workflow run build.yaml --field non_continuous=true

Note:

• the marvinpinto/action-automatic-releases action has been dropped in favor of just using the GitHub CLI executable:
  • the marvinpinto/action-automatic-releases repo is archived
  • there were some warnings about using set-output (deprecated) during execution
• release notes are generated with git log (from the previous continuous or persistent release tag, depending on the release type)
• persistent releases are still marked as "Pre-release"

[probonopd]

Hi @benoit-pierre. We never want to create a non-continuous release.

The way I imagine to tag releases is that a continuous release which has not had grave bugs reported against it in a few weeks will get renamed (but not rebuilt).

This imho is the only viable strategy, as building another release would require the binaries to be retested.

Does this make sense?

[github-actions]

Build for testing:
artifacts
Use at your own risk.

[benoit-pierre]

Only in the sense that this means there's basically zero build reproducibility… Which I guess, considering the use of continuous releases everywhere in the build script is to be expected.

Anyway, we can't rename the continuous release (or rather, we don't want to loose it and break workflows relying on it), but we can download the assets and create/push a new release with those assets.

I'll amend.

[probonopd]

My point is that I want the exact binary bytes that have proven to be working to become the tagged release.

Why can't we rename the existing continous release to a tagged name, and just run a new build to create another continuous release? That's more like my mental model here...

[benoit-pierre]

It does not make sense to me to rebuild a new continuous release if nothing changed (no new commits).

[benoit-pierre]

Updated persistent release mechanism:

Add a new workflow to create a new persistent release based on the current continuous release:
- from GitHub's website actions' tab: select the "Create Persistent Release" workflow, then click on "Run workflow" and trigger a run.
- using the cli: gh workflow run release.yaml

Examples: https://github.com/benoit-pierre/go-appimage/releases

[probonopd]

Add a new workflow to create a new persistent release based on the current continuous release

Wouldn't this result in new binaries being built for the non-continuous release? That's not what I want. I would like the known-good continuous release (including its known-good binaries) to be renamed to a non-continuous release. (That's what I've been doing manually in my other projects.)

If my explanation is not sufficient or does not make sense, please let me know. Again, thanks for your help!

[benoit-pierre]

Add a new workflow to create a new persistent release based on the current continuous release

Wouldn't this result in new binaries being built for the non-continuous release?

No, the same binaries are used, see the workflow, nothing is rebuilt.

[Copilot]

Pull request overview

This PR fixes version reporting discrepancies in AppImage tools and adds support for creating persistent releases. The main issue addressed is that the version shown by --help (e.g., 177) didn't match the version in the filename (e.g., 823), which was actually 177+646. The PR also modernizes the release process by replacing the archived marvinpinto/action-automatic-releases GitHub Action with direct GitHub CLI commands.

Key changes:

• Consolidated version and commit handling in build.sh to use a unified BUILDID variable that includes both version and commit hash
• Created a new release.sh script to handle both continuous and persistent releases using GitHub CLI
• Added a new release.yaml workflow for creating persistent releases from continuous release assets

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 10 comments.

File	Description
scripts/release.sh	New script that manages both continuous and persistent releases using GitHub CLI, with automatic release note generation from git log
scripts/build.sh	Refactored version/commit variable handling to create a unified BUILDID that includes both version and commit hash for accurate reporting
.github/workflows/release.yaml	New workflow for creating persistent releases by downloading continuous release assets and republishing them
.github/workflows/build.yaml	Updated to use GitHub CLI directly for continuous releases, removed deprecated action, and configured environment variables for version tracking

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.