Hadoop Event Recovery: add continuous deployment

[fblundun]

This is working now that I have moved from Travis's S3 integration to a custom script uploading to S3.

The way I have implemented it is slightly different from the implementation for the Kinesis apps, in that at the moment the version in the tag doesn't actually do anything - it's the version defined in BuildSettings.scala which determines the name of the jar. (For the Kinesis apps, the version in the tag determines the name of the zip file.)

This seems a bit illogical - is there a better way to do it?

[fblundun]

cc @ninjabear @alexanderdean @jbeemster @chuwy

[ninjabear]

Hey @fblundun ! The simplest thing you can do is to enforce the tag version matches with the version in BuildSettings.scala prior to deployment - make the build fail if the tag and the version isn't correct (exiting with 1 in a bash script will do this).

To do this from a script, the tag is an environment variable provided by travis - $TRAVIS_TAG and you can grab the version of a SBT project using sbt version. Here's an example used in the scala tracker:

https://github.com/snowplow/snowplow-scala-tracker/blob/master/.travis/deploy.sh#L17-L18

[alexanderdean]

This sounds great, thanks @ninjabear

[alexanderdean]

Hmm, sorry I just re-read the above, spoke too soon. What's the proposal for tagging in this repository to relate to Hadoop Event Recovery?

[fblundun]

sbt lets you set the version for the current session. So we could extract the version from the tag, then do

sbt <<EOF
set version := "0.5.0"
assembly
EOF

[alexanderdean]

I'm not convinced by using tags to drive the versions being built... I like having the versions of each application visible in source control at a given commit. Also, this starts to get very complicated fast when you have e.g. Hadoop Enrich pulling in the latest version of Common Enrich - how do you express that version dependency if it's all tag-driven?