Backwards Compatible CI Build & Release for Both Tagged and Untagged

[jmkao]

Generate releases for both tagged and untagged builds. Tagged builds will be deployed to Github Releases and show up on the project page as a pre-release version based on the tag name. Then from the releases page in Github, they can be changed into release versions. Both tagged and untagged builds will also be sent to bintray, which will hold the newest release in a Development-Stream version.

Backwards compatibility: generate traditional numbered builds, except when environment variable CI=true, which is the case in travis. This will allow the current binary commit with start.sh to function while generating tagged and untagged releases in travis, so that when we update start.sh, there will be something to actually grab from the Github Releases.

The build.number file will contain both a tag or commit identifier to a particular point in code, and the traditional build number. The existing grep/awk logic in start.sh still functions despite the addition. Filenames generated by CI and uploaded to a release will contain both the tag/commit hash and the traditional build number.

Connected to #143

[jmkao]

@WesGilster since you generate all the stable builds, have a look and see if you're comfortable with this.

[WesGilster]

I wouldn't say I'm comfortable, but I think catching on.

What values will be returned from the git execution and into the git.revision property? I'm missing that part of the build.

I'm also missing how/where env.ci was set.

[jmkao]

The CI environment variable is only set when the build runs in travis, which populates the value automatically.

The git target execution will populate ${repo.version} with either the name of the tag of the commit (e.g. "DEV001" or "DEV002" in the case of the sample releases at https://github.com/area515/Creation-Workshop-Host/releases) or the first 5 digits of the commit's hash, like the "af98b" you see in this build:

https://travis-ci.org/area515/Creation-Workshop-Host/builds/114142051

That hash can be used to identify the commit that was the source to that build by appending it to the end of the commit list URL, like:

https://github.com/area515/Creation-Workshop-Host/commit/af98b

Based on the CI environment variable, when the build is run outside of Travis CI, it should do the same thing that it does today, creating builds named only with the value of build.number and incrementing the value.

Inside of Travis CI, it will begin populating releases based on tags, so essentially we'll be releasing both the "old" and the "new" way simultaneously.

Then, the only thing left to do to switch to the "new" way would be to update the logic in start.sh. Doing it this way, we could in theory keep the last version of the binary in the repo after the change so that older versions would pull it and then upgrade to the new way of doing things.

[jmkao]

Hmm.. there's a conflict on this now. Let me take these changes and put them on a branch based on WesGilster/Creation-Workshop-Host. I can then submit the PR to your dev repo and you can try out the changes for yourself, and if you're okay with them, you can merge them back to area515 with the rest of your queued up features.