Build and upload AppImage

[probonopd]

This PR, when merged, will compile Advanced Mac Substitute for Linux on Travis CI upon each git push, and upload an AppImage to your GitHub Releases page.

Providing an AppImage would have, among others, these advantages:

• Applications packaged as an AppImage can run on many distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
• One app = one file = super simple for users: just download one AppImage file, make it executable, and run
• No unpacking or installation necessary
• No root needed
• No system libraries changed
• Works out of the box, no installation of runtimes needed
• Optional desktop integration with appimaged
• Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
• Can optionally GPG2-sign your AppImages (inside the file)
• Works on Live ISOs
• Can use the same AppImages when dual-booting multiple distributions
• Can be listed in the AppImageHub central directory of available AppImages
• Can double as a self-extracting compressed archive with the --appimage-extract parameter
• No repositories needed. Suitable/optimized for air-gapped (offline) machines

Here is an overview of projects that are already distributing upstream-provided, official AppImages.

PLEASE NOTE: For this to work, you need to set up GITHUB_TOKEN in Travis CI for this to work; please see https://github.com/probonopd/uploadtool.
If you would like to see only one entry for the Pull Request in your project's history, then please enable this GitHub functionality on your repo. It allows you to squash (combine) the commits when merging.

If you have questions, AppImage developers are on #AppImage on irc.freenode.net.

[probonopd]

AppImages for testing are available at https://github.com/probonopd/metamage_1/releases:

• Advanced_Mac_Substitute-*-x86_64.AppImage runs the Welcome application
• Lode_Runner-*-x86_64.AppImage runs the embedded Lode Runner application

[jjuran]

Thanks for your effort and patience in getting this working. I have several concerns, though.

Foremost, I don't feel comfortable hosting Lode Runner on my GitHub account. Fortunately, the Internet Archive is already providing that service.

Second, I don't think the metamage_1 repository is the right place for project-specific CI. It would mean that every commit in every unrelated project would trigger a new build. Worse, potentially necessary new commits in ams-68k-bin or freemount wouldn't trigger new builds. A possible alternative is an integration repository that combines the relevant parts of the three input repos, which would be less data to clone and a more appropriate site for CI.

Third, does having a ready-made package of every change really benefit users? Those who want to dig into specific points in commit history can do so, of course, but I think most users would be best served by a more deliberate release process.

Please let me know if there's something I've missed.

[probonopd]

Foremost, I don't feel comfortable hosting Lode Runner on my GitHub account. Fortunately, the Internet Archive is already providing that service.

This is mainly an example of how easy it is to bundle an application; of course it can easily be disabled.

Second, I don't think the metamage_1 repository is the right place for project-specific CI. It would mean that every commit in every unrelated project would trigger a new build.

Which is awesome, isn't it? That's the point of "continuous" builds...

Worse, potentially necessary new commits in ams-68k-bin or freemount wouldn't trigger new builds. A possible alternative is an integration repository that combines the relevant parts of the three input repos

Well, that would never be triggered automatically. Or do you know a way to do this?

Third, does having a ready-made package of every change really benefit users?

For me personally, I always only care about the latest. But different people have different interests; you can create releases in addition and an AppImage will be generated for those too.