Automate publication of release artifacts

[adamvoss]

This automates part of step 2 from the existing I-D Publish Process. With this all that should be required is pushing the tag and no manually building/uploading files necessary.

This will hopefully make the process easier to follow since this publication did not occur with draft-06.

Note: api_key will need to be updated. See also #370.

From 3c2ad180d5dd28d9c102f0d7deef5079c003dc8c Mon Sep 17 00:00:00 2001
From: Adam Voss <vossad01@gmail.com>
Date: Wed, 7 Jun 2017 12:48:03 -0500
Subject: [PATCH 1/1] Add automatic deployment to Travis CI build

When a tag is pushed, it will publish the build on GitHub releases.
---
 .travis.yml | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/.travis.yml b/.travis.yml
index 05f9525..c5b1e00 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -7,3 +7,14 @@ script:
 - xml2rfc jsonschema-core.xml --basename=jsonschema-core-$TAG --text --html
 - xml2rfc jsonschema-validation.xml --basename=jsonschema-validation-$TAG --text --html
 - xml2rfc jsonschema-hyperschema.xml --basename=jsonschema-hyperschema-$TAG --text --html
+deploy:
+  provider: releases
+  api_key:
+    secure: GwqBAv10t3T5wW9Q28Zr+QH93kGNGHInZk92VbEeZ+2Efnx2wtrb/XgMaQYjuTkk6DSWVPzoOkiON9iEY62EkD37F4M4Xd8pgQmeOR46zwT568daH+M49/2/HnHlzejHInFNa+0hxy2LjTXZt2Bvqoi9Hb7o6c0IdMwbAX3NrqNc6Ky2UPDoXZuUz6Rbz/6vWsNwEMEKn52Zsmgg6OVw1skZe+2ZaHDCH1TkTLmlk1IgXHTZHMXn3LcPv8tzx/yoPzjIpojzeg+TbAYApzB6UL7d81i4pb4PzmKsWp1UPEHI/nWDbeK8GucYN4BrfK22vKoSgdASfgL8LfWhSvwdz8CskjT2Lr+o+kF+3dMfOwyh9mMTtuqhHdW82pgvKIURrz7oSMDzkeDSg+bjz/BkU5lmuJPSTCMWYaGb9d295Azn+pRTN7wbrxpnGnUodcvtDFijIldhJh9q12iWBdfgLXfWeUOvrtZCQDldPhMerk9oiUJjTtZnlZkKxSZZWAhGEDP86XTa4XvKPC/R9WiQRtpwbdR/DtQQyFxfLJZ1gnsQYAJuI0KQ4PWkB8fI3Cvlime9/BI3d5YmsZvNiNviKn4m4fgAk0amV7N6z40laoWZ8y+laHxdBdMfD3MG8QS9ncLZJ7rfTUT9RAoPhFAa8lodI3wXk7PR7XbhKjmwczM=
+  skip_cleanup: true
+  file:
+  - "*.html"
+  - "*.txt"
+  file_glob: true
+  on:
+    tags: true
-- 
2.7.4

[handrews]

Having looked into this more and read up on GitHub releases, I don't think they are a good fit for this project. The appropriate delivery mechanism is through the IETF web site, not offering packaged downloads. I do not want to have a parallel release process.

Also, the part that got skipped for draft-06 was doing the tags, which isn't addressed here.

[adamvoss]

Will you remove the self-rendered specs from the website then and link only to the IETF publications?

Also, you will need to update the wiki process doc with this new approach.

[handrews]

No, I just mean that this "shipping software to end users" paradigm is not what we're doing here, and the release process is fine as it is. https://github.com/blog/1547-release-your-software

It's done roughly twice a year. As the person who will do it next, I don't want to pipe it through GitHub's software distribution channels for a trivial amount of automation.

[adamvoss]

I don't want to pipe it through GitHub's software distribution channels for a trivial amount of automation.

I am a confused because your process says to publish it on GitHub Releases. The only difference this would have made with respect to that is that Travis would have done it via the GitHub API rather than a human doing it via the GitHub web site. I am not sure how that makes it a different distribution channel.

[handrews]

[EDIT: I keep changing my mind, see further comments, sorry]

@adamvoss if you want to submit this as a PR I'll approve it. I assume if it breaks and causes Travis to freak out somehow and you're not around I can just revert the commit.

[handrews]

@adamvoss actually, I'll approve it if it will work with all of the following:

• uniform tagging (everything is -wright-02 and published at the same time)
• mixed simultaneous tagging (some are -wright-02 and some are -handrews-00 and published at the same time)
• staggered tagging (we tag and push the core and validation first, and then relative pointer and hyper-schema later, or any other combination)

[handrews]

[NEVER MIND THE COMMENT THAT WAS HERE (I was confused by the releases page)

[handrews]

OK, still wrestling with this. It looks like this was only ever done for one release. Even in the old repo, while there are two rather cryptic tags there are not public releases.

Since Austin's only responding to things sporadically these days I don't know why he started doing that for one release and then didn't for the next. My inclination is to remove the public release (or make it a private draft since it doesn't look like it can be deleted?). And, yes, update the release process documentation as you asked.

The proper channels are the IETF site and our own web site. We don't need a third distribution channel (and TBH I'm a little dubious about having them on the web site - for instance cbor.io links to their IETF doc, not a self-hosted build).

[handrews]

I've updated the wiki page https://github.com/json-schema-org/json-schema-spec/wiki
I've notified the other contributors of my intention to delete the one published release. That should remove the need for this process entirely.