spring-hateoas/ci

== Spring HATEOAS CI

Spring HATEOAS uses Concourse as it's CI tool of choice. This provides support for:

* Pipeline against the `master` branch
* Support for pull requests

=== Creating a pipeline

Using the `fly` command, you can execute a series of commands to create multiple pipelines to manage everything. But
first, some critical credentials are needed.

Create a `credentials.yml` file like this:

[source,yml]
----
github-access-token: <your Personal Access Token from github>
docker-email: <your docker hub email address>
docker-username: <your docker hub username>
docker-password: <your docker hub password>
artifactory-username: <your artifactory username>
artifactory-password: <your artifactory encoded password>
----

WARNING: Do NOT check this file into source control! If you'll check, `credentials.yml` is listed in `.gitignore` to prevent this.

With this in place, run the following `fly` commands to create pipelines:

----
% fly -t spring-data sp -p spring-hateoas -c ci/pipeline-template.yml -l credentials.yml -v branch=master
----

With this pipeline in place, you can now activate and expose it:

----
% fly -t spring-data unpause-pipeline -p spring-hateoas
% fly -t spring-data expose-pipeline -p spring-hateoas
----

=== Making a release

1. Create a new release (on the main branch).
----
% ci/create-release.sh <ticket> <release version> <next snapshot version>
----

NOTE: Because <ticket> starts with `#`, it must be prefix on the command line with `\`, e.g.
`ci/create-release.sh \#123 1.0.0.M1 1.0.0.BUILD-SNAPSHOT`.

2. With the release tagged, push the tagged version to the release branch.
----
% git checkout -b release
% git reset --hard <tag>
% git push -f origin release
----

NOTE: You can chain the previous set of commands together using `&&`.

=== Running CI tasks locally

Since Concourse is built on top of Docker, it's easy to:

* Debug what went wrong on your local machine.
* Test out a a tweak to your `test.sh` script before sending it out.
* Experiment against a new image before submitting your pull request.

All of these use cases are great reasons to essentially run what Concourse does on your local machine.

IMPORTANT: To do this you must have Docker installed on your machine.

1. `docker run -it --mount type=bind,source="$(pwd)",target=/spring-hateoas-github openjdk:8-jdk /bin/bash`
+
This will launch the Docker image and mount your source code at `spring-hateoas-github`.
+
Next, run the `test.sh` script from inside the container:
+
2. `PROFILE=none spring-hateoas-github/ci/test.sh`

Since the container is binding to your source, you can make edits from your IDE and continue to run build jobs.

If you need to test the `build.sh` script, then do this:

1. `mkdir /tmp/spring-hateoas-artifactory`
2. `docker run -it --mount type=bind,source="$(pwd)",target=/spring-hateoas-github --mount type=bind,source="/tmp/spring-hateoas-artifactory",target=/spring-hateoas-artifactory openjdk:8-jdk /bin/bash`
+
This will launch the Docker image and mount your source code at `spring-hateoas-github` and the temporary
artifactory output directory at `spring-hateoas-artifactory`.
+
Next, run the `build.sh` script from inside the container:
+
3. `spring-hateoas-github/ci/build.sh`

IMPORTANT: `build.sh` doesn't actually push to Artifactory so don't worry about accidentally deploying anything.
It just deploys to a local folder. That way, the `artifactory-resource` later in the pipeline can pick up these artifacts
and deliver them to artifactory.

NOTE: Docker containers can eat up disk space fast! From time to time, run `docker system prune` to clean out old images.