Make it easier in appimagetool to produce valid update information and .zsync files

[probonopd]

Adoption of update information and .zsync files still leaves to be deserved.

Feedback is that currently implementing update information is too cumbersome, e.g., @ivan-hc (who is very dedicated and spends lots of time) saying

Too many developers does not include this update system with metadata... me included (because I think the documentation is too complicate).

And indeed, putting together valid and working update information and .zsync files is too cumbersome.

So, can we think of input (environment variables) and outputs (stdout, stderr) to make this easier?
E.g. whenever we detect that GitHub Actions environment variables are set, we could construct the update information like this (pseudo-code to get across the idea):

#!/bin/sh

# Check if GitHub Actions environment variables are set
if [ -n "${GITHUB_REPOSITORY}" ]; then
  # Split GITHUB_REPOSITORY into actor and repository
  REPO_PARTS=(${GITHUB_REPOSITORY//\// })
  USER=${REPO_PARTS[0]}
  REPO=${REPO_PARTS[1]}

  # Construct the update information using GitHub Actions environment variables
  UPDATE_INFO="gh-releases-zsync|${USER}|${REPO}|latest|${APPIMAGE_NAME}-*${ARCH}.AppImage.zsync"

  # Set the update information as an environment variable
  export APPIMAGE_UPDATE_INFORMATION=${UPDATE_INFO}

  # Print the constructed update information
  echo "APPIMAGE_UPDATE_INFORMATION=${UPDATE_INFO}"
fi

We might use that automatically detected update information and make appimagetool print out a message saying something like

If you want to make your AppImage updateable, use the --make-updatable argument; it will then use the following update information: $APPIMAGE_UPDATE_INFORMATION"

If the user then indeed uses --make-updatable, appimagetool should embed the update information, produce the .zsync file, and output very clear instructions on how and where to upload the files (under which URLs they must be hosted) and how to test that it all works.

@TheAssassin I hope that this proposal addresses your dislike of "automagic" solutions, while still achieving the desired effect of "nudging" users to using update information.

[TheAssassin]

"Autodetection" has proven to be problematic in the past in appimagetool and that is the main reason I dislike it. For instance, a variety of AppImages I use are built on GitHub actions. The creators do not upload the .zsync files, though. I'd have to open issues and convince them of their use. But still, the very naive default update approach will not be suitable for enterprise software, for instance. That is why libappimageupdate exists and is used by some companies' products.

I don't mind autodetection, but I'd strongly advocate for making it opt-in, ideally with some very stark advertising in appimagetool's output (i.e., "looks like you're on GitHub actions, please read here how to easily enable updates" linking to docs.appimage.org).

TL;DR: I think we can make this work. But please beware of the problems I mentioned. I'm sure there are more things to consider, too.

[probonopd]

Yes, that is what I suggested above (anticipating your concerns): Detect when we are running on GitHub Actions, and then asking (strongly recommending) the user to opt in. Once opted in, generate the update information and .zsync, and display the user very clear instructions under which URLs he must publish the files in order for it to work.