| Table of Contents |
|---|
...
In the pom.xml add in the plugin along with the proper scm link (make sure that the scm link matches the project's github repo). The example below is from revalidation:
<scm>
<developerConnection>scm:git:git@github.com:Health-Education-England/TIS-REVALIDATION.git</developerConnection>
<tag>HEAD</tag>
</scm>
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-release-plugin</artifactId>
<version>2.5.2</version>
<dependencies>
<dependency>
<groupId>org.apache.maven.scm</groupId>
<artifactId>maven-scm-provider-gitexe</artifactId>
<version>1.9.4</version>
</dependency>
</dependencies>
</plugin>
You should start with common projects that are required for others to compile (such as TIS-SHARED-MODULES).
...
The above rolls back your attempt to release and deletes the tag you set (ofcourse change the code to the tag you need).
Validating Docker Versions
The build pipeline now tags the Docker images so both images and containers can be inspected to validate their build settings.
...
To inspect the concerns image, for example, run the following on the dev server;
| Code Block |
|---|
$ export SERVICE=concerns
$ docker inspect -f '{{ index .Config.Labels "com.transformuk.hee.tis.build_version" }}' docker-hee.transformcloud.net:5000/hee/${SERVICE}:latest |
To inspect the build version of a container is a bit eaiser;
| Code Block |
|---|
$ docker inspect -f '{{ index .Config.Labels "com.transformuk.hee.tis.build_version" }}' concerns_concerns_1 |
It is a useful sanity check to make sure that the latest tag on dev is the version you expect.
Once you have established the versions of the images, they can be added to the stage/platform.yml or prod/platform.yml if they are ready to release.
UI Projects (npm and bower):
At the time of writing only TIS-COMMON is UI only.
...