Skip to content

Commit ca5610e

Browse files
committed
SWS-1068 - Upgrade CI.
1 parent 0e48b4c commit ca5610e

File tree

2 files changed

+245
-94
lines changed

2 files changed

+245
-94
lines changed

ci/README.adoc

Lines changed: 47 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -27,7 +27,7 @@ WARNING: Do NOT check this file into source control! If you'll check, `credentia
2727
With this in place, run the following `fly` commands to create pipelines:
2828

2929
----
30-
% fly -t spring-team sp -p spring-ws -c ci/pipeline-template.yml -l credentials.yml -v branch=master -v release-branch=release
30+
% fly -t spring-team sp -p spring-ws -c ci/pipeline-template.yml -l credentials.yml -v branch=master
3131
----
3232

3333
With 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

4242
1. 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
50-
% git reset --hard <tag>
51-
% git push -f origin release
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

Comments
 (0)