CI: upload binaries when a release is published

[LKedward]

This PR updates the CI so that it is additionally triggered when a github release is published to which it will upload binaries (Linux, Mac, Windows) for both versions of fpm as release assets (example here).

As discussed at last month's meeting, this simplifies the bootstrapping process (on the supported platforms) and also simplifies using fpm in your own CI.

After running the usual tests, the CI checks that the release tag, of the form vx.y.z, matches that output by fpm --version;
binaries are not uploaded if the release tag does not match (example workflow)

For the time being, releases can be created by maintainers at their own discretion as features are added and bugs fixed (I'm happy to do this); in the long term, a release process will need to be discussed and documented.

I intend to create an initial release (v0.1.0) following this PR.
Resolves #218.

[awvwgk]

Binaries work fine on my own machines. I couldn't get the Haskell version running on my local HPC cluster (old OpenSUSE), since it is not statically linked (not sure if this is even possible with Haskell). So nothing unexpected, but something to keep in mind.

One minor thing: Could we generate some SHA256 hashes for each release artefact?

Also, how are prerelease events handled?

[milancurcic]

This is a great addition, thank you!

The Ubuntu executables are compatible with other Linuxes in general, no? If yes, let's just call it "linux" instead of "ubuntu".

I also suggest the following naming convention for the executable file names:

fpm-<version>-<os>-<arch>[.exe]

instead of

fpm-<os>-<version>-<arch>[.exe]

where <version> is either version ("x.x.x") or "latest". What do you think?

I noticed that the Linux binary comes as not executable so I had to set that by hand first. I think we should add the "x" permission to Linux and macOS binaries.

[LKedward]

One minor thing: Could we generate some SHA256 hashes for each release artefact?

Good point; yep I'll add them in.

Also, how are prerelease events handled?

They should be treated the same as a normal release - I'll check tomorrow.

Thanks @milancurcic, yes I agree about the naming - I'll reorder with the actual version number in and add +x permission.

---

@everythingfunctional, do you know if compilation of statically-linked binaries is possible with Haskell stack?

[LKedward]

Thanks for reviewing; I've updated the file naming convention as suggested and added hashes for checking integrity.
Unfortunately I can't seem to preserve executable permissions on the Linux/MacOS binaries when added as assets - I think this may be a limitation (or security feature?) of github.

[awvwgk]

It is probably a security feature. One option to preserve the permissions would be packaging in a tarball/zip archive instead, but this would increase the “installation barrier” slightly.

[LKedward]

If there are no objections or further comments I will merge later today and create an initial release with tag 'v0.1.0'.

[LKedward]

I've created a tag v0.1.0 and corresponding release, for which the workflow has executed successfully and there are now binaries to download. Since this is the first release, instead of a change-log I have simply summarised the features currently supported in each version.