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