pack
pack copied to clipboard
buildpacks
Understand Spring Boot Git Properties
In a recent change to the CNB specification, support for adding source metadata to the created image's label was added. This spec change was designed for the case where the input to pack is a repository of source code and the buildpacks create images from that source. In this case, extraction of the source information by pack is pretty straight forward. However, there is a use-case where the input to pack is a recompiled artifact (say a Spring Boot JAR) rather than the source repository, preventing pack from determining the source metadata.
Luckily, Spring Boot natively supports embedding Git metadata into the created JAR file. pack should optionally detect this metadata if it exists, and use it for the contents of the image's source metadata.
Technical Details
The Spring Boot Maven and Gradle plugins both optionally embed this metadata. By default the location of this file is BOOT-INF/classes/git.properties. This location can be moved, but finding it at a non-default location should be out of scope of this effort.
This file follows the Java Properties File format. An example of the created file, including the standard keys, follows:
#Generated by Git-Commit-Id-Plugin
#Fri Jan 10 10:52:34 PST 2020
git.branch=master
git.build.host=hypnotoad.local
git.build.time=2020-01-10T10\:52\:34-0800
[email protected]
git.build.user.name=Ben Hale
git.build.version=2.0.0.BUILD-SNAPSHOT
git.closest.tag.commit.count=
git.closest.tag.name=
git.commit.id=63a73f1b0f2a4f6978c19184b0ea33ad3f092913
git.commit.id.abbrev=63a73f1
git.commit.id.describe=63a73f1-dirty
git.commit.id.describe-short=63a73f1-dirty
git.commit.message.full=Spring Boot 2.2.2.RELEASE\n\nSigned-off-by\: Ben Hale <[email protected]>
git.commit.message.short=Spring Boot 2.2.2.RELEASE
git.commit.time=2019-12-12T17\:56\:38-0800
[email protected]
git.commit.user.name=Ben Hale
git.dirty=true
git.local.branch.ahead=0
git.local.branch.behind=0
git.remote.origin.url=https\://github.com/nebhale/apps-manager-demo.git
git.tags=
git.total.commit.count=20
Various properties should be extracted out of this content and mapped to the expected fields in the source metadata payload.
Is there a reason this should live in pack (the platform) vs a buildpack? Aren’t we sort of coupling here? I’d worried that supporting this specific case (spring) in the platform would lead to others. Maybe technically this intelligence has to live on the platform because it handles the input to the buildpacks?
Correct @zmackie. This is properly located in each platform because only the platform can reliably examine source information before sanitizing it for build. An example of this is that each platform will need to implement support for VCSs such as Git, Mercurial, Subversion, CVS, P4, etc. because we plan to filter out things like the .git/ directory before putting it into the build containers (i.e. buildpacks won't even have enough information to extract this information if they wanted to). Adding support for other ways of communicating source information, including from the built artifacts of the most popular enterprise frameworks, is along the same lines.
Just discussed it with @pivotal-david-osullivan , yes it would be nice to have, it's on our radar
