Utilize GitHub Releases API for TRAVIS deployments

[esilvia]

Utilize GitHub Releases API for TRAVIS deployments

[hobu]

GitHub Releases wasn't super mature when I was doing this stuff in February. It has gotten better, but you're right that individual tagging of releases to trigger things can be problematic. A deficiency with our current setup is only in-org Pull Requests PDFs can be uploaded because the secure credentials are only available to the org. This shouldn't be a problem for most of our contributors since we're all within the organization. Outsiders can still contribute pull requests to us, we just don't get rendered output until we merge them up.

[hobu]

I'm 👎 on this for a few reasons:

• It complicates our deployment to have to manage another set of encrypted credentials (first AWS to dump to my S3 bucket and now GitHub's)
• We don't want a "release" for every commit on the repo (we have that now with the S3 bucket, but they're not indexed by google or anything else and you have to dig to get the URLs to the files).
• When documents are finalized, the chair should take a copy of the generated document, name it, and post it in the appropriate (and canonical) ASPRS.org location -- not here in our workspace.

I think we should continue with the current approach for a few releases until it is clear we need to automate things further. Even getting this far was quite a leap.

[esilvia]

Now that I've looked into this more than when I initially created this issue, I agree with your assessment.