Shall we set up an automated build of the shadow jar?

[DanVanAtta]

Related to #216, which is a check list of the steps that will be needed to complete this. To get a start, we need the bot account to be given appropriate access permissions.

---

To finish an automated release pipeline of the 'shadow jar', a release artifact we publish today, all that is needed from the admins is to grant write access to the 'shared bot' account 'tripleabuilderbot', I can modify the .travis.yml file to then finish the rest, and provide admins with the bot account credentials.

In this issue, I want to see if there are any questions/comments/concerns, and if there is agreement to the plan. If there is agreement to move forward, I'll create an issue with a checklist of the steps that would need to happen (not too many of them, but again, only one needed from admins). If there is agreement to the final checklist we can then move to executing on this phase of the build and release automation project.

For more context, the bot account needs write access to be able to push tags and to deploy artifacts to releases. Otherwise the .travis.yml file will be updated to look really similar to the below (and note, this is the only file that will need to be modified, no updates to the gradle file, it already does the shadow jar build today):

Example of how .travis.yml will look

language: java
jdk:
- oraclejdk8
install: true
script:
- gradle zipMap
before_deploy:
- git config --global user.email "tripleabuilderbot@gmail.com"
- git config --global user.name "tripleabuilderbot"
- export MAP_TAGGED_VERSION="$MAP_VERSION.$TRAVIS_BUILD_NUMBER"
- git tag $MAP_TAGGED_VERSION -a -m "$MAP_TAGGED_VERSION"
- git push -q https://$GITHUB_PERSONAL_ACCESS_TOKEN_FOR_TRAVIS@github.com/triplea-maps/$REPO_NAME --tags
deploy:
  provider: releases
  api_key:
    secure: sTJxC1pAb5Q+hMTQAAr7BmdDHuUryGil+qgEr6rZkxmOPGqMQzsSemcwmzflR6+IWw6HQvcwJBUwXsItlhuHIGheolW9gKZY4mSc9LqH0z7xF/+YwG74h/2fv7EttQ19f5TLwF25AzgoSexbbuZcWPk4w/Qaewdg4s5qPkHpw8DXmIzjrIcZg+zIUoCJRDDidJ02AlXm4bgDI8upiD34ckjJMIO4z5tkiASvuADpxyqlBmcLinlNnq2gAOQt7gBbBOakz91bUSFxS0V+NtekZauRLel356EibCqe2VHb+PsZ1cblAJ5XhqSpz4NN8ZupRS/kxM0s3ZNP0imX4630cqqZnX20/ZoeADtiRwsau6FZj60uF3WQlqUM5ZzggRTW9oGjwCreaIjyvYbzBsEOrZKiT8vYPrUTufAHEH1LOJlFvKlwBy3Gm/Rk4CSllZ2dj88MNT3GtzdNmNK6IEqBjyZKtrmy9fUxaCihVDrNI2xpAXFDlZMpXrktbEIIL8oYgjl6wj+tWJHKMvhQxKnVRMZoJ9BOrh6rx4b+GYehXWS9/j+ZZl9gt6enE30rTn4K4UmtQ+8Jw1fb3Dx4cyLxw4ummS9nowAZGUx0J/8qasnyy50BxpdqLse9afZHivjqVnTk4kdqeDw2ClKZ9CO6hpf+AkIOefR0H5zxAzgsWX4=
  file: "$REPO_NAME.zip"
  skip_cleanup: true
  prerelease: true
  on:
    tags: false
    all_branches: true

This stack overflow gave steps for auto-pushing tags: http://stackoverflow.com/questions/28217556/travis-ci-auto-tag-build-for-github-release

[DanVanAtta]

@veqryn , @ron-murhammer , @gaborbernat - initial thoughts? Would be nice to move on this sooner while there is still context and nothing to be re-learned.

[DanVanAtta]

I would like to introduce tripleabuilderbot, willing, ready and eager to help us with all of our triplea building needs:

[gaborbernat]

I for one are in favor of this.

I'm really sorry for all the delays regarding the installer, I'm going on a trip today and tomorrow, but hopefully I can start looking into this tomorrow night. Sorry 👍 September turned out to be a really hectic month for me 😭

[DanVanAtta]

@ron-murhammer , @veqryn , this is blocked until you guys review and grant write access to the bot account 'tripleabuilderbot'. It's a very minimal ask on your part to get this going forward, should take about 3 minutes total once you decide to grant the access.

[ron-murhammer]

@DanVanAtta Some questions:

1. Does it make more sense for the builder to be inside the triplea-game organization? Is that even possible?
2. Will this be tagging/releasing the jar on every commit to master? Or based on something else?
3. What will the format of the tags look like?
4. Are we also looking to use the bot for the actual release artifacts (exe, dmg, etc) when we put out a new version?

[DanVanAtta]

Does it make more sense for the builder to be inside the triplea-game organization? Is that even possible?

To move forward the builder needs to be added as a team member of the triplea-game organization and given write permission. The builder account is just another GitHub user account with a dedicated Gmail address. Like any Github user account, it can belong to any number of teams and organizations.

To keep things simple, the intent is to share the bot between the maps and the game engine organizations. The SSH keys in the account remain secure even if you have the account password. Regardless, the account password will be revealed to only a very few people (I expect that to likely include just the current game engine admins, and maybe not even myself once the one time set up has been done).

Will this be tagging/releasing the jar on every commit to master? Or based on something else?

Automatic tagging will happen when a commit is pushed to master. That will then be followed by an automatic release whenever a tag is pushed. There is a small and very important tweak present in the config to ensure that tags don't spawn new tags which would then spawn yet more new tags.

If we adopt this process, we can with not too much effort update the build process to automatically prune "pre-release" tags so we would just retain only 10 or 20 of them.

What will the format of the tags look like?

Depends if pushed manually or automatically. If pushed manually, the automated release process will use the tag value verbatim as the game engine version.

If a tag is automatically generated, the travis build number is appended to an environment variable that stores the game engine version number. This means that as is, after stable releases we will want to update the value of the game engine version in the Travis web UI.

Are we also looking to use the bot for the actual release artifacts (exe, dmg, etc) when we put out a new version?

Yes!
It will be triggered by pushing a tag manually. Since the bot will have already tested out the packaging and build process on every commit since the prior release, - we will have much more confidence that the build and release process are still working correctly.

[ron-murhammer]

@DanVanAtta Alright, makes sense to me and thanks for the clarifications. Obviously, since we will be giving the bot write access we'll need to be careful to keep credentials to a limited group and monitor the bot closely as we get it setup to make sure it isn't spawning infinite tags or anything crazy :)

To be clear the only things it will use write access for initially are:

1. Creating tags after each commit.
2. Building jar and uploading to releases after each commit.

Is that correct? Or am I missing anything?

[DanVanAtta]

The bot has been pretty well tested with the map repo's happily. The .travis.yml config sample in the original post is taken from a map repository. It is a working example, the bot has been behaving well: http://github.com/tripleabuilderbot?tab=activity.

Initially @ron-murhammer , that sounds like the correct list. Soon we'll hopefully have it pushing OS installers as well. Then eventually cleaning up pre-release tags. Beyond that, I don't see any other usages at this time.

[ron-murhammer]

@DanVanAtta Alright. Looks good in the map repo's. I'm good with this though since we are granting write access I'd like veqryn to at least acknowledge it.

@veqryn Please review and approve.

[DanVanAtta]

@veqryn I'd like to get this automation in place for an automated release pipeline so we can forget about it and start benefiting from it. Please give your okay so I can spend the 10 minutes doing the needful to get it set up.

[veqryn]

Interesting idea. Approved. Please mail ron and I the credentials.

[DanVanAtta]

@veqryn , I emailed both you and @ron-murhammer the bot account details.

I submitted #248 which has the .travis.yml updates.

Next we'll need that merged and the bot given write access.

From there I can generate another token which will be used for pushing tags. Then with the bot account I can set the token as a secret environment variable in the Travis Web UI along with a variable for the 'build version'. Then with a bit of luck it'll then work.