Add schemas tarball to releases

[flaw]

Applicable Issues

GH-201

Description of the Change

It simply packages the content of the schemas folder in event-types.tar.gz, and configures travis to deploy the tarball whenever a release is tagged in GH.

Note that the encrypted secret key currently in tarvis.yml corresponds to my fork of the repo, that will have to be updated by someone with admin access.
The easiest way is to use the travis-cli as described in https://docs.travis-ci.com/user/deployment/releases/

Also worth noting is that I haven't actually been able to test that Travis does what it's supposed to do in this case. For some reason Travis has decided that me doing this change is a potentially abusive action and therefore I must wait for their support to get back to me.
shrug

Alternate Designs

As discussed in #201 an alternative to this would have been to split the schemas to a separate repository which could be used as a submodule without pulling in all sorts of unrelated nonsense, but that had it's own problems. This was the best compromise we came up with.

Benefits

Downstream implementations can use the Releases API to pull in the schema tarball during build time for tools such as jsonschema-2-pojo

Possible Drawbacks

Not that many.

Sign-off

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or

(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or

(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.

(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.

Signed-off-by: Sami Paavilainen sami.paavilainen@wartsila.com

[d-stahl-ericsson]

Thank you! Would you be ok with including only the latest version of each event type? It's a bit more elaborate, but something that has been requested previously: easy access to only the event versions of a particular edition. Perhaps produce two tars per release: event-schemas-all and event-schemas-latest?

[flaw]

Hmm, I'll see what I can do. Need to actually think about how to use it downstream as well, I just realized that as things stand most tools will probably try to generate something like 1_1_0.java due to how the schemas are named.

Would you be opposed to having the event-schemas-latest contain the latest version of the schemas, renamed as the actual event types? The schemas themselves seem to contain the version info already so I don't think any crucial information would be lost.

[d-stahl-ericsson]

I think that would be perfect. And of course it would be best to store them in a flat structure in that case.

[d-stahl-ericsson]

Looks good to me. I replaced the api_key directly in the PR, hope you don't mind.

I'm not sure if there's any way we can test this properly without merging, but as far as I can tell this looks sound. Anyone else?

[flaw]

Don't mind at all. I made the tar calls and the script verbose on purpose so we can at least see from the travis logs that it's doing more or less what it's intended to do, the tar v flag and the print from the script can be removed later if someone is allergic to them.

[e-backmark-ericsson]

It looks good to me as well. Nice code!
Wouldn't it be suitable with some short info in a readme somewhere on how you could pull in the generated schema tars using the GitHub APIs? For example under 'About this repository' on the top README? Unless you dig for it it might not be apparent for everyone that those tar files exist.

[flaw]

In general a few words about how Eiffel editions are released would be nice; stuff like how is the decision to tag a new edition made (quarterly, on-demand, something else entirely), perhaps something about the event versioning.
That'd be a decent place to promote the existence of the event schemas as well.

I can add some usage examples later on once I actually do use them.

[e-backmark-ericsson]

I approve this change. Updates of the documentation on how to use the generated artifacts can be added later.

[d-stahl-ericsson]

I'm struggling to get it to work. The configuration appears to be ok and Travis CI reports success, but no Assets show up in GitHub. Let me know if you spot anything that's not right. I've mailed Travis CI support.

[flaw]

Should've guessed, the exact use case depicted in the documentation never works straight up.
Seems you got it working on the latest test release, but what did you change?

[d-stahl-ericsson]

I've been troubleshooting with Travis CI support. Apparently the working directory is not reset between blocks in the configuration, so the deployment executes from within the subdir.

[d-stahl-ericsson]

All done!