Embed update information in x64 AppImage

[TheAssassin]

Pull Request Type

• Bugfix
• Feature Implementation
• Documentation
• Other

Related issue

#6863 (Does not really close it, as this only implements the feature for amd64; CI is a little complex, and I think it might be possible to set update information with electron-builder, too, which should do the trick for the remaining architectures)

Description

Makes amd64 AppImages easily updatable with AppImageUpdate.

See AppImageCommunity/AppImageUpdate@be4eb63 and AppImage/AppImageSpec@6932f73 for the changes required in AppImage tooling.

Once this project leaves the pre-release status, the latest-all magic value will also update to stable releases which might then just use latest (maps to non-prereleases only). Basically switching to "stable release channel" automatically. You can then also implement latest-pre in prereleases to establish a prerelease channel.

Screenshots

Testing

1. Build AppImage with GitHub actions
2. Try to update it with AppImageUpdate (won't work until there is a release uploaded with the .zsync file that AppImageUpdate needs for its delta update mechanism, but you should see an error message à la "could not find file" rather than "this AppImage does not support updating")

I've tested the basic concept in my fork already.

Desktop

• OS: Linux
• OS Version: doesn't matter
• FreeTube version: doesn't matter either

Additional context

Note that this "add static runtime" workaround should not be needed any more; we have officially released the static runtime and our tools use it automatically, too. Not sure about electron-builder in general, but it might be worth checking. In that case, you can remove some complexity from your CI workflow.

[TheAssassin]

Note that this PR already prepares the update of the .zsync files for all the platforms. It's just not implemented for anything but amd64. I am not too much into Electron and electron-builder, but the update information should be configured there as well ideally.

[absidue]

To quote the original pull request #5747 that added the extra step of extracting the original AppImage and then recreating one with the static runtime:

I was not able to fix this on the arm builds because even though I tried using the same runners that the upload actions for those use, it complains that it can't execute the appimage to extract it, which is needed in order to convert it.

So unless you know a way of extracting an AppImage without running it (the Linux build runners are x64, which is why it's possible to do it for the x64 AppImage) or manage to change the AppImage generation in electron-builder to directly create an AppImage with a static runtime and update information, the x64 AppImage will be the only one with the static runtime and update information for the foreseeable future.

Or is there a way to patch the update information directly into an existing AppImage without extracting it?

[absidue]

These changes are to the wrong workflow file, the build workflow runs on the development branch to create the nightly builds which are uploaded to the GitHub workflow artifacts (unrelated to releases and require a GitHub login to download), please revert these changes and modify the release workflow instead.

[TheAssassin]

So unless you know a way of extracting an AppImage without running it (the Linux build runners are x64, which is why it's possible to do it for the x64 AppImage) or manage to change the AppImage generation in electron-builder to directly create an AppImage with a static runtime and update information, the x64 AppImage will be the only one with the static runtime and update information for the foreseeable future.

There is an upstream issue which you may want to second to maybe make them merge the corresponding PR. Technically, the static runtime should be used for all AppImages anyway. I don't think it makes sense to replace it after installing electron-builder either.

It is possible to parse the AppImage payload offset from the ELF header, but that is kind of complex, I wouldn't recommend it. Then, it could be extracted with unsquashfs. But you could just install qemu-user-static in the runners, too, and emulate-run the AppImages. One can also use the x86_64 runtime to extract an AppImage: TARGET_APPIMAGE=my.AppImage ./runtime --appimage-extract.

Or is there a way to patch the update information directly into an existing AppImage without extracting it?

The update information space in the ELF header should be editable, but I'd probably just run appimagetool over all AppImages on the release page then using the method proposed above.

[TheAssassin]

Please note that actions/upload-release-asset@v1 is apparently deprecated and also very elaborate. In fact, the entire workflow is largely copy-and-paste. Some more templating or the use of other tools might help.