@@ -28,7 +28,7 @@ WARNING: Do NOT check this file into source control! If you'll check, `credentia
2828With this in place, run the following `fly` commands to create pipelines:
2929
3030----
31- % fly -t spring-team sp -p spring-session-data-mongodb -c ci/pipeline-template.yml -l credentials.yml -v branch=master -v release-branch=release
31+ % fly -t spring-team sp -p spring-session-data-mongodb -c ci/pipeline-template.yml -l credentials.yml -v branch=master
3232----
3333
3434With this pipeline in place, you can now activate and expose it:
@@ -45,11 +45,50 @@ With this pipeline in place, you can now activate and expose it:
4545% ci/create-release.sh <release version> <next snapshot version>
4646----
4747
48- 2. With the release tagged, push the tagged version to the release branch .
48+ 2. With the release officially tagged, just push it to master .
4949----
50- % git checkout -b release
51- % git reset --hard <tag>
52- % git push -f origin release
50+ % git push
5351----
5452
55- NOTE: You can chain the previous set of commands together using `&&`.
53+ The pipeline will pick up the next tag and release it. It will also build a new snapshot and stage it on artifactory.
54+
55+
56+ === Running CI tasks locally
57+
58+ Since Concourse is built on top of Docker, it's easy to:
59+
60+ * Debug what went wrong on your local machine.
61+ * Test out a a tweak to your `test.sh` script before sending it out.
62+ * Experiment against a new image before submitting your pull request.
63+
64+ All of these use cases are great reasons to essentially run what Concourse does on your local machine.
65+
66+ IMPORTANT: To do this you must have Docker installed on your machine.
67+
68+ 1. `docker run -it --mount type=bind,source="$(pwd)",target=/spring-session-data-mongodb-github openjdk:8-jdk /bin/bash`
69+ +
70+ This will launch the Docker image and mount your source code at `spring-session-data-mongodb-github`.
71+ +
72+ Next, run the `test.sh` script from inside the container:
73+ +
74+ 2. `PROFILE=none spring-session-data-mongodb-github/ci/test.sh`
75+
76+ Since the container is binding to your source, you can make edits from your IDE and continue to run build jobs.
77+
78+ If you need to test the `build.sh` script, then do this:
79+
80+ 1. `mkdir /tmp/spring-session-data-mongodb-artifactory`
81+ 2. `docker run -it --mount type=bind,source="$(pwd)",target=/spring-session-data-mongodb-github --mount type=bind,source="/tmp/spring-session-data-mongodb-artifactory",target=/spring-session-data-mongodb-artifactory openjdk:8-jdk /bin/bash`
82+ +
83+ This will launch the Docker image and mount your source code at `spring-session-data-mongodb-github` and the temporary
84+ artifactory output directory at `spring-session-data-mongodb-artifactory`.
85+ +
86+ Next, run the `build.sh` script from inside the container:
87+ +
88+ 3. `spring-session-data-mongodb-github/ci/build.sh`
89+
90+ IMPORTANT: `build.sh` doesn't actually push to Artifactory so don't worry about accidentally deploying anything.
91+ It just deploys to a local folder. That way, the `artifactory-resource` later in the pipeline can pick up these artifacts
92+ and deliver them to artifactory.
93+
94+ NOTE: Docker containers can eat up disk space fast! From time to time, run `docker system prune` to clean out old images.
0 commit comments