feat: Automatically publish artifacts to GitHub

[seanprashad]

Fixes #17: Automatically publish artifacts to GitHub

This PR allows successful Travis builds to publish the target/release directory to Github releases for Supernova.

[seanprashad]

Travis docs for GitHub releases uploading contains more details on configuration options.

[seanprashad]

TODO: Test this on one of my own repos by creating a tag and having Travis build and upload the release.

[0xazure]

Hey @seanprashad really exited to get this pipeline integrated into the project!

You mention that you'd be looking for me to generate the API token to enable this integration; how should we combine your work with that piece of data you need from me?

Really happy to see the sha1sum calculation, verifying download integrity is useful especially since we're moving these files between a few different systems.

How does provider: releases interact with the build matrix we've already got implemented? We're building on linux/windows x stable/beta/nightly (6 separate build results), how does it differentiate the build environment configurations and make sure the files are all uniquely named?

Ideally I'd like to see something like supernova-{major.minor.patch}-{platform}-{arch} on the Releases page, possibly as a compressed/archived file that contains the compiled artifact, the license(s) and maybe some documentation/README. I'm looking at https://github.com/rustwasm/wasm-pack/releases for inspiration on how we could organize the artifacts.

[seanprashad]

I haven't forgotten about this - just have my ✋ ✋ tied with other coursework right now

[0xazure]

No worries! Thanks for the update.

[0xazure]

Hey @seanprashad, just wanted to check in and see how this pull request is going.

[0xazure]

We were discussing the encrypted API token to enable direct upload of build artifacts to GitHub, and I think we might be better served by defining this kind of credential in the repository settings, especially because it's a value that should probably not be automatically available to forks as only the upstream master branch should upload build artifacts automatically.

@seanprashad let me know what you think the best direction would be, and a name for the env var, I can get it added to the repository settings a lot more quickly than creating & encrypting it before sending to you and it should be available immediately on this pull request so you can test it out.

[seanprashad]

Sweet - I think the repo setting will be just as good. Can we use GH_TOKEN for the name? That will replace this:

GH_TOKEN: &GH_TOKEN
script:
    secure:

with this:

api_key: `GH_TOKEN`

I'll also beef up the conditional settings for when we are going to deploy by adding repo: 0xazure/supernova. This means that a release will only get deployed if:

1. The current checked out branch is master
2. The repo is 0xazure/supernova
3. A new tag is added to a commit on master and pushed to 0xazure/supernova (git push --tag origin). This will trigger a build to deploy artifacts from Travis

[seanprashad]

https://github.com/SeanPrashad/supernova/releases 🎉

[seanprashad]

@0xazure I know testing this patch will be quite tricky which is why I've added you to my fork that is setup with Travis.

I would recommend testing out the following four scenarios:

1. Pushing new commits directly to master should trigger a build, resulting in nothing uploaded to GitHub Releases

2. Pushing new commits into a new branch which should trigger a build, resulting in nothing uploaded to GitHub Releases

3. Create and push a new tag should trigger a build, resulting in new artifacts uploaded to GitHub Releases

4. Create and push a new tag whilst on a master should trigger a build, resulting in new artifacts uploaded to GitHub Releases

5. Create and push a new tag whilst on a new branch should trigger a build, resulting in new artifacts uploaded to GitHub Releases

Just make sure to leave this branch, issue-17 untouched 😄

[0xazure]

Can we use GH_TOKEN for the name?

Done, I've added it to the Travis env variables for supernova.

Agreed with the four scenarios, artifacts should only be uploaded for tagged releases on master.

[seanprashad]

Should note that tags don't need to be made on master as they essentially act as their own "branch".

This means that we can tag any branch, push to GitHub and it'll upload artifacts to GitHub Releases.

See an example here for v.0.0.19:

[0xazure]

Suggested change

	repo: SeanPrashad/supernova
	repo: 0xazure/supernova

I think this slipped through during testing, but I know it was complicated flipping between projects and branches.

[0xazure]

Hey @seanprashad awesome job on this! I know how much testing and troubleshooting you had to go through on Travis to get this working, so I really appreciate all the work you've put in.

It's super exciting to get automated build artifacts added to GitHub releases, because this will let us distribute precompiled source binaries to many different platforms in a lot of different packaging methods.

Thanks again! 🎉