Use Github releases

[Flamefire]

The github releases API seems to be pretty good by now. How about using it?

We can create releases for each tag and/or for each commit. This would solve the problem with the outdated compilers and libraries and e.g. getting the OSX cross-compiler to work.

Even nightly builds will work: See https://github.com/OoliteProject/nightlies/releases for an example.

Downsides:

• Only full archives would work, so no more incremental updates (but those are ~30MB which I'd deem acceptable to download as an update)
• Updater has to be adjusted. I think we can keep most of the functionality (automatic update, version check, savegame warning) but needs some work.

Some more resources:

• https://stackoverflow.com/questions/5207269/releasing-a-build-artifact-on-github
• GitHub Releases causes multiple releases with linux and osx travis-ci/travis-ci#8053
• https://stackoverflow.com/questions/51349200/create-nightly-releases-wiht-multiple-artifacts-on-github-via-travis

[Flow86]

you still need to create the binaries by yourself, so it wont help on that problem?

[Flamefire]

How do you mean that? Travis and appveyor create binaries and test them. They can also upload them to Github. So as long as the stuff compiles on travis there is no problem. And as travis supports OSX native compiling we don't have to fiddle with the cross-compiler.
We can build the windows binaries with mingw on travis too but thats harder. But as appveyor supports github releases too we can build natively for all platforms. But I'd drop linux 32 Bit support from the official binaries (not sure how to do that on travis and most OSes are 64Bit anyway now)

[baka0815]

Is there an automatic way to remove those nightlies after some time?
Otherwise there might be hundreds of builds after a while...

[Flamefire]

Yes, kinda. The API of Github releases allows to query all releases, edit and delete them. We could ad this as a separate step: Query all releases, then delete all but the most recent 50(?) nightlies

[Flamefire]

I did create a test repo to try this. The result is this: https://github.com/Flamefire/release-tests/releases

It uses git stages and a python script for creating the release: https://github.com/j0057/github-release

The workflow is as follows:

1. Create and run tests
2. Create a release draft
3. Build and upload binaries for OSX and linux
4. Publish release

Each has its own stage, so if any run in any stage fails, no others will be run.

Problems:

• Windows...
  • Travis may support windows builds soon or we could use mingw there too.
  • We can simply use appveyor and upload to the same release.
    • Introduces a race condition on who creates the release, but should be ok
• Linux 32Bit
  • Dropped as irrelevant nowadays
• Failed builds result in drafts
  • Should not happen, as no direct pushing to master and PRs are tested
  • Automatic deletion of drafts will be possible: Delete enhancement scikit-build/github-release#51
• Nighlies may accumulate a lot
  • Same as above. We could delete all nightlies older than a couple months when publishing a new one
• No Incremental updates
  • This is a problem. It is possible to create multiple assets, but as fine grained as before might be problematic
  • Maybe use the current update server to pull in releases from github once they are uploaded? Then we can keep our current updater.

Again big advantage: Native builds -> no hassle with cross-compiling and keeping the software up to date

[Flamefire]

Windows/Appveyor now works too: https://github.com/Flamefire/release-tests/releases/tag/Nightly-20181014-f4956f0