The images built by the Spring Boot Maven and Spring Boot Gradle plugins do not have OCI image annotations, such as org.opencontainers.image.source

These annotations are useful for people to manual use as well as for use by tools. For example, Snyk uses them in its UI and Renovate uses them to find release notes.

I believe at least these labels should be added to the images: * org.opencontainers.image.source * org.opencontainers.image.revision * org.opencontainers.image.version

Currently, it's possible to manually add these labels, enabled by the image-labels buildpack which is included by default. For example, with gradle:

tasks.named("bootBuildImage") {
    // See: https://github.com/paketo-buildpacks/image-labels
    // See: https://github.com/opencontainers/image-spec/blob/main/annotations.md#pre-defined-annotation-keys)
    // GitLab: https://docs.gitlab.com/ee/ci/variables/predefined_variables.html
    // GitHub: https://docs.github.com/en/actions/learn-github-actions/variables
    // Azure DevOps Pipelines: https://learn.microsoft.com/en-us/azure/devops/pipelines/build/variables
    java.util.Optional.ofNullable(
        System.getenv("CI_PROJECT_URL")
         ?: ( System.getenv("GITHUB_SERVER_URL") ? "${System.getenv("GITHUB_SERVER_URL")}/${System.getenv("GITHUB_REPOSITORY")}" : null)
         ?: System.getenv("BUILD_REPOSITORY_URI")
    ).ifPresent { environment["BP_OCI_SOURCE"] = it }
    java.util.Optional.ofNullable(
        System.getenv("CI_COMMIT_SHA")
        ?: System.getenv("GITHUB_SHA")
        ?: System.getenv("BUILD.SOURCEVERSION")
    ).ifPresent { environment["BP_OCI_REVISION"] = it }
    environment["BP_OCI_VERSION"] = project.version
}

Relevant documentation: https://github.com/paketo-buildpacks/image-labels

I think this information should be set automatically, not requiring the user to do any such manual configuration.

Comment From: scottfrederick

I agree that there is value in having the org.opencontainers.image.* labels set on image automatically, but the suggested approach is not the right way to do this. There are too many variations in the source of the suggested information for Spring Boot to make guesses about the source.

In addition, Spring Boot is actively moving away from setting environment variables to influence buildpack behavior, as environment variables are specific to a buildpack vendor and should be reserved for end-user configuration. See #32829 and #32884 for examples of efforts to move away from setting environment variables for buildpacks. We prefer to put hints in the build artifacts (jar or war files) such as META-INF/MANIFEST.MF entries that any buildpack vendor could choose to use.

The Paketo Buildpack for Spring Boot already adds the labels org.opencontainers.image.title and org.opencontainers.image.version based on Implementation-Title and Implementation-Version entries in META-INF/MANIFEST.MF in the jar file provided to the buildpack. It would be better for this buildpack to expand on that and add the labels you suggested from manifest entries that you could configure your build tool to add to the jar or war. You could start a discussion on that in the buildpack's GitHub project.

Comment From: candrews

Implementation-Version entries in META-INF/MANIFEST.MF

I don't see Implementation-Version in the META-INF/MANIFEST.MF produced by my Spring Boot 3.0.2 project, so I'm thinking the first step is to get Spring Boot to populate META-INF/MANIFEST.MF with that information. Would Spring Boot be open to doing that by default (if so I'll open an issue)?

Comment From: scottfrederick

Maven will generate the Implementation-* entries with some configuration. I don't see a need for us to do anything there since it comes built-in with Maven.

There is at least one plugin available for Gradle that provides similar functionality. I'm not sure we'd want to add this functionality to the Spring Boot Gradle plugin given that it's already possible without much effort. I'll tag this to see what other team members think.

Comment From: candrews

I think telling users to have to setup a separate Gradle plugin or modify Maven configuration for something that would benefit them and therefore should be expected to Just Work ™️ goes against the design objectives of Spring Boot:

takes an opinionated view of the Spring platform so that new and existing users can quickly get to the bits they need.

Comment From: wilkinsona

We've configured Maven's jar plugin to add the Implementation-* entries since 1.2.1. We don't do the same for Gradle. Arguably that's a bug as we generally aim for consistency between the two build systems.

Comment From: scottfrederick

Good catch, Andy. I've created #34059 to address the inconsistency between the Spring Boot Maven and Gradle plugins.