paketo-buildpacks / base-builder Goto Github PK

Context
Once we start publishing the Base Builder to the official Dockerhub and GCR locations (see: https://github.com/paketo-buildpacks/builder/issues/33), we should start publishing simple user facing release notes per release.

For now, this should be as simple as:
(Proposal below)

To use this builder with pack:
pack inspect-builder paketobuildpacks/builder:<VERSION>-base
pack build my-app --builder paketobuildpacks/builder:<VERSION>-base

➜ pack inspect-builder paketobuildpacks/builder:<VERSION>-full                                                            
Inspecting builder: paketobuildpacks/builder:<VERSION>-full                                                            

REMOTE:

Description: Ubuntu bionic base image with buildpacks for Java, NodeJS and Golang

Created By:
  Name: Pack CLI
  Version: 0.13.1+git-4134cc6.build-1135

Trusted: No

Stack:
  ID: io.buildpacks.stacks.bionic

Lifecycle:
  Version: 0.9.1
  Buildpack APIs:
    Deprecated: (none)
    Supported: 0.2, 0.3, 0.4
  Platform APIs:
    Deprecated: (none)
    Supported: 0.3, 0.4

Run Images:
  index.docker.io/paketobuildpacks/run:base-cnb
  gcr.io/paketo-buildpacks/run:base-cnb

Buildpacks:
  ID                                                  VERSION        HOMEPAGE
  paketo-buildpacks/java                              3.0.1          https://github.com/paketo-buildpacks/java
  paketo-buildpacks/sbt                               3.1.0          https://github.com/paketo-buildpacks/sbt
  paketo-buildpacks/dist-zip                          2.2.0          https://github.com/paketo-buildpacks/dist-zip
  paketo-buildpacks/encrypt-at-rest                   2.2.0          https://github.com/paketo-buildpacks/encrypt-at-rest
  paketo-buildpacks/executable-jar                    3.1.0          https://github.com/paketo-buildpacks/executable-jar
  paketo-buildpacks/google-stackdriver                2.2.0          https://github.com/paketo-buildpacks/google-stackdriver
  paketo-buildpacks/image-labels                      2.0.2          https://github.com/paketo-buildpacks/image-labels
  paketo-buildpacks/procfile                          2.0.2          https://github.com/paketo-buildpacks/procfile
  paketo-buildpacks/azure-application-insights        2.2.0          https://github.com/paketo-buildpacks/azure-application-insights
  paketo-buildpacks/gradle                            3.1.0          https://github.com/paketo-buildpacks/gradle
  paketo-buildpacks/leiningen                         1.1.0          https://github.com/paketo-buildpacks/leiningen
  paketo-buildpacks/maven                             3.1.0          https://github.com/paketo-buildpacks/maven
  paketo-buildpacks/spring-boot                       3.2.0          https://github.com/paketo-buildpacks/spring-boot
  paketo-buildpacks/apache-tomcat                     2.2.0          https://github.com/paketo-buildpacks/apache-tomcat
  paketo-buildpacks/debug                             2.1.1          https://github.com/paketo-buildpacks/debug
  paketo-buildpacks/environment-variables             2.1.0          https://github.com/paketo-buildpacks/environment-variables
  paketo-buildpacks/bellsoft-liberica                 3.2.0          https://github.com/paketo-buildpacks/bellsoft-liberica
  paketo-buildpacks/jmx                               2.1.1          https://github.com/paketo-buildpacks/jmx
  paketo-buildpacks/java-native-image                 3.1.2          https://github.com/paketo-buildpacks/java-native-image
  paketo-buildpacks/graalvm                           3.2.1          https://github.com/paketo-buildpacks/graalvm
  paketo-buildpacks/spring-boot-native-image          1.2.1          https://github.com/paketo-buildpacks/spring-boot-native-image
  paketo-buildpacks/nginx                             0.0.193        https://github.com/paketo-buildpacks/nginx
  paketo-buildpacks/dotnet-core                       0.0.8          https://github.com/paketo-buildpacks/dotnet-core
  paketo-buildpacks/dotnet-core-aspnet                0.0.190        https://github.com/paketo-buildpacks/dotnet-core-aspnet
  paketo-buildpacks/dotnet-core-build                 0.0.119        https://github.com/paketo-buildpacks/dotnet-core-build
  paketo-buildpacks/dotnet-core-conf                  0.0.177        https://github.com/paketo-buildpacks/dotnet-core-conf
  paketo-buildpacks/dotnet-core-runtime               0.0.195        https://github.com/paketo-buildpacks/dotnet-core-runtime
  paketo-buildpacks/dotnet-core-sdk                   0.0.192        https://github.com/paketo-buildpacks/dotnet-core-sdk
  paketo-buildpacks/icu                               0.0.97         https://github.com/paketo-buildpacks/icu
  paketo-buildpacks/node-engine                       0.0.262        https://github.com/paketo-buildpacks/node-engine
  paketo-buildpacks/go                                0.1.0          https://github.com/paketo-buildpacks/go
  paketo-buildpacks/go-build                          0.0.32         https://github.com/paketo-buildpacks/go-build
  paketo-buildpacks/go-dist                           0.1.0          https://github.com/paketo-buildpacks/go-dist
  paketo-buildpacks/go-mod-vendor                     0.0.164        https://github.com/paketo-buildpacks/go-mod-vendor
  paketo-buildpacks/dep                               0.0.169        https://github.com/paketo-buildpacks/dep
  paketo-buildpacks/dep-ensure                        0.0.30         https://github.com/paketo-buildpacks/dep-ensure
  paketo-buildpacks/nodejs                            0.0.6          https://github.com/paketo-buildpacks/nodejs
  paketo-buildpacks/node-start                        0.0.3          
  paketo-buildpacks/npm                               0.1.80         https://github.com/paketo-buildpacks/npm
  paketo-buildpacks/yarn-install                      0.1.87         https://github.com/paketo-buildpacks/yarn-install

Detection Order:
 ├ Group paketo-buildpacks/builder#1:
 │  └ paketo-buildpacks/[email protected]    
 │     └ Group paketo-buildpacks/builder#1:
 │        ├ paketo-buildpacks/[email protected]                     
 │        ├ paketo-buildpacks/[email protected]                      (optional)
 │        ├ paketo-buildpacks/[email protected]                   (optional)
 │        ├ paketo-buildpacks/[email protected]                       (optional)
 │        ├ paketo-buildpacks/[email protected]                         (optional)
 │        ├ paketo-buildpacks/[email protected]              (optional)
 │        ├ paketo-buildpacks/[email protected]                 (optional)
 │        ├ paketo-buildpacks/[email protected]    
 │        ├ paketo-buildpacks/[email protected]                    (optional)
 │        ├ paketo-buildpacks/[email protected]       (optional)
 │        └ paketo-buildpacks/[email protected]                (optional)
 ├ Group paketo-buildpacks/builder#2:
 │  └ paketo-buildpacks/[email protected]    
 │     └ Group paketo-buildpacks/builder#1:
 │        ├ paketo-buildpacks/[email protected]             
 │        ├ paketo-buildpacks/[email protected]                        (optional)
 │        ├ paketo-buildpacks/[email protected]                     (optional)
 │        ├ paketo-buildpacks/[email protected]                         (optional)
 │        ├ paketo-buildpacks/[email protected]                           (optional)
 │        ├ paketo-buildpacks/[email protected]                (optional)
 │        ├ paketo-buildpacks/[email protected]                 (optional)
 │        ├ paketo-buildpacks/[email protected]                      (optional)
 │        ├ paketo-buildpacks/[email protected]                   (optional)
 │        ├ paketo-buildpacks/[email protected]                      (optional)
 │        ├ paketo-buildpacks/[email protected]    (optional)
 │        ├ paketo-buildpacks/[email protected]                         (optional)
 │        ├ paketo-buildpacks/[email protected]            (optional)
 │        ├ paketo-buildpacks/[email protected]                           (optional)
 │        ├ paketo-buildpacks/[email protected]               (optional)
 │        ├ paketo-buildpacks/[email protected]         (optional)
 │        └ paketo-buildpacks/[email protected]                  (optional)
 ├ Group paketo-buildpacks/builder#3:
 │  └ paketo-buildpacks/[email protected]    
 │     ├ Group paketo-buildpacks/builder#1:
 │     │  ├ paketo-buildpacks/[email protected]    
 │     │  └ paketo-buildpacks/[email protected]    
 │     ├ Group paketo-buildpacks/builder#2:
 │     │  ├ paketo-buildpacks/[email protected]    
 │     │  └ paketo-buildpacks/[email protected]             
 │     └ Group paketo-buildpacks/builder#3:
 │        ├ paketo-buildpacks/[email protected]    
 │        └ paketo-buildpacks/[email protected]       
 ├ Group paketo-buildpacks/builder#4:
 │  └ paketo-buildpacks/[email protected]    
 │     ├ Group paketo-buildpacks/builder#1:
 │     │  ├ paketo-buildpacks/[email protected]            
 │     │  ├ paketo-buildpacks/[email protected]    
 │     │  └ paketo-buildpacks/[email protected]          
 │     ├ Group paketo-buildpacks/builder#2:
 │     │  ├ paketo-buildpacks/[email protected]        
 │     │  ├ paketo-buildpacks/[email protected]          
 │     │  ├ paketo-buildpacks/[email protected]    
 │     │  └ paketo-buildpacks/[email protected]      
 │     └ Group paketo-buildpacks/builder#3:
 │        ├ paketo-buildpacks/[email protected]      
 │        └ paketo-buildpacks/[email protected]    
 ├ Group paketo-buildpacks/builder#5:
 │  └ paketo-buildpacks/[email protected]    
 │     └ Group paketo-buildpacks/builder#1:
 │        ├ paketo-buildpacks/[email protected]            (optional)
 │        ├ paketo-buildpacks/[email protected]                     (optional)
 │        ├ paketo-buildpacks/[email protected]    (optional)
 │        ├ paketo-buildpacks/[email protected]     (optional)
 │        ├ paketo-buildpacks/[email protected]        (optional)
 │        ├ paketo-buildpacks/[email protected]      (optional)
 │        └ paketo-buildpacks/[email protected]       
 ├ Group paketo-buildpacks/builder#6:
 │  └ paketo-buildpacks/[email protected]    
 └ Group paketo-buildpacks/builder#7:
    └ paketo-buildpacks/[email protected]    

Per RFC 0042, we should re-order the builder.

This will constitute a minor version bump of the builder.

If you are building a Java application with Maven or Gradle, and front end resources are built using Node.js as part of the Java build process, you don't want the buildpack to think you are a Node.js application. Sample code example: https://github.com/dsyer/spring-boot-angular or https://github.com/dsyer/spring-boot-js-demo/tree/main/nodejs. Example output from one of those samples:

$ pack build dsyer/nodejs
...
===> DETECTING
5 of 10 buildpacks participating
paketo-buildpacks/ca-certificates 3.0.1
paketo-buildpacks/node-engine     0.11.2
paketo-buildpacks/npm-install     0.6.2
paketo-buildpacks/node-module-bom 0.2.0
paketo-buildpacks/npm-start       0.6.1
...

There's a workaround, which is to set BP_NODE_PROJECT_PATH to a directory that doesn't have any node content. E.g.

$ pack --env BP_NODE_PROJECT_PATH=target build dsyer/nodejs
...
===> DETECTING
8 of 19 buildpacks participating
paketo-buildpacks/ca-certificates   3.0.1
paketo-buildpacks/bellsoft-liberica 9.0.1
paketo-buildpacks/syft              1.3.0
paketo-buildpacks/maven             6.0.1
paketo-buildpacks/executable-jar    6.0.1
paketo-buildpacks/apache-tomcat     7.0.2
paketo-buildpacks/dist-zip          5.0.1
paketo-buildpacks/spring-boot       5.2.0
===> RESTORING
...

What happened?

Running standard Maven build, started failing on Friday 27th May in the afternoon, presumably coincident with the new version release (0.2.70-base).

• What were you attempting to do?
  Standard "build-image" gaol that I have been using for months.

• What did you expect to happen?
  Maven build to succeed and generate the container image.

• What was the actual behavior? Please provide log output, if possible.
  [INFO] ------------------------------------------------------------------------
  [INFO] BUILD FAILURE
  [INFO] ------------------------------------------------------------------------
  [INFO] Total time: 33.497 s
  [INFO] Finished at: 2022-05-30T09:56:31+01:00
  [INFO] ------------------------------------------------------------------------
  [ERROR] Failed to execute goal org.springframework.boot:spring-boot-maven-plugin:2.6.7:build-image (build-oci-image) on project my-service: Execution build-oci-image of goal org.springframework.boot:spring-boot-maven-plugin:2.6.7:build-image failed: Invalid response received when loading image "pack.local/builder/fotudltqlm:latest" -> [Help 1]
  org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.springframework.boot:spring-boot-maven-plugin:2.6.7:build-image (build-oci-image) on project my-service: Execution build-oci-image of goal org.springframework.boot:spring-boot-maven-plugin:2.6.7:build-image failed: Invalid response received when loading image "pack.local/builder/fotudltqlm:latest"
  at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:306)
  at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:211)
  at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:165)
  at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:157)
  at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:121)
  at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
  at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
  at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:127)
  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294)
  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
  at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
  at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
  at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke (Method.java:566)
  at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
  at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
  at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
  at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
  Caused by: org.apache.maven.plugin.PluginExecutionException: Execution build-oci-image of goal org.springframework.boot:spring-boot-maven-plugin:2.6.7:build-image failed: Invalid response received when loading image "pack.local/builder/fotudltqlm:latest"
  at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:148)
  at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:301)
  at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:211)
  at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:165)
  at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:157)
  at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:121)
  at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
  at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
  at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:127)
  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294)
  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
  at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
  at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
  at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke (Method.java:566)
  at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
  at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
  at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
  at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
  Caused by: java.lang.IllegalStateException: Invalid response received when loading image "pack.local/builder/fotudltqlm:latest"
  at org.springframework.util.Assert.state (Assert.java:76)
  at org.springframework.boot.buildpack.platform.docker.DockerApi$ImageApi.load (DockerApi.java:243)
  at org.springframework.boot.buildpack.platform.build.Builder.build (Builder.java:111)
  at org.springframework.boot.maven.BuildImageMojo.buildImage (BuildImageMojo.java:230)
  at org.springframework.boot.maven.BuildImageMojo.execute (BuildImageMojo.java:220)
  at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
  at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:301)
  at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:211)
  at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:165)
  at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:157)
  at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:121)
  at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
  at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
  at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:127)
  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:294)
  at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
  at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
  at org.apache.maven.cli.MavenCli.execute (MavenCli.java:960)
  at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:293)
  at org.apache.maven.cli.MavenCli.main (MavenCli.java:196)
  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
  at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
  at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
  at java.lang.reflect.Method.invoke (Method.java:566)
  at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
  at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
  at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
  at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
  [ERROR]
  [ERROR]
  [ERROR] For more information about the errors and possible solutions, please read the following articles:
  [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException

Reverting to builder version 0.2.69-base resolves the problem.

Build Configuration

    <plugin>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-maven-plugin</artifactId>
      <executions>
        <execution>
          <id>build-oci-image</id>
          <goals>
            <goal>build-image</goal>
          </goals>
        </execution>
      </executions>
      <configuration>
        <image>
          <builder>paketobuildpacks/builder:base</builder>
          <buildpacks>
            <buildpack>gcr.io/paketo-buildpacks/graalvm:latest</buildpack>
            <buildpack>gcr.io/paketo-buildpacks/java:latest</buildpack>
          </buildpacks>
          <env>

...

Checklist

I have included log output.
The log output includes an error message.
I have included steps for reproduction.
I have included work-around.

I am using paketo build packs with Spring Boot for Native Container Images + Maven.
And because of some limitations of flyway, I have the requirement to add an additional directory with content to the image.
JIb has a property "extraDirectories" to achieve this.
But diving into paketos documentation i could not find something similar.
So is there something that can be activated by some <BP_XX> Parameter ?

Otherwise i have to leverage JIB or a Dockerfile afterwards

Thank you in advance

This repo should automatically cut releases of the base-builder when there are changes to the builder.toml on the main branch. See Builder RFC #3

Now that the paketo samples
repo has tests for each sample
app, it would be ideal if the smoke tests in this repo, which run on new PRs,
used those sample apps and tests.

The tests on this repo should run the sample app tests for all of the language
families that are compatible with this builder. These tests should be runnable
with scripts/smoke.sh and should run automatically in all of the workflows
where the smoke tests currently run.

Notably, the scripts and .github directories for this builder are kept in
sync with the builders directory in the Paketo github
config
repo. Some of the changes required to make this testing work will have to
happen in that repo.

This way, we can have confidence that builders remain compatible with the
existing supported set of app configurations.

What happened?

• What were you attempting to do?

I am trying to install certain app-specific dependencies using apt in custom buildpack, where base-builder is the builder image using this tutorial.

• What did you expect to happen?

I expect the dependencies to be installed on the base builder image as part of the image building lifecycle. The expected solution is either an option like user as which the builder should be run or default support for cnb user to install dependencies.

• What was the actual behavior? Please provide log output, if possible.

An error that permission denied accessing the apt package lists. Adding sudo says command not found. Since the builder image runs as user cnb, this issue occurs.

Reading package lists...
E: List directory /var/lib/apt/lists/partial is missing. - Acquire (13: Permission denied)
ERROR: failed to build: exit status 100
ERROR: failed to build: executing lifecycle: failed with status code: 145

Build Configuration

• What platform (pack, kpack, tekton buildpacks plugin, etc.) are you using? Please include a version.

$ pack --version
0.19.0+git-360dbae.build-2550

• What buildpacks are you using? Please include versions.

In the use case I am just trying to test the custom buildpack

• What builder are you using? If custom, can you provide the output from pack inspect-builder <builder>?

I am using the paketo-buildpacks/builder:base.

$ pack inspect-builder paketobuildpacks/builder:base
Inspecting default builder: paketobuildpacks/builder:base

REMOTE:

Description: Ubuntu bionic base image with buildpacks for Java, .NET Core, NodeJS, Go, Ruby, NGINX and Procfile

Created By:
  Name: Pack CLI
  Version: 0.19.0+git-360dbae.build-2550

Trusted: Yes

Stack:
  ID: io.buildpacks.stacks.bionic

Lifecycle:
  Version: 0.11.3
  Buildpack APIs:
    Deprecated: (none)
    Supported: 0.2, 0.3, 0.4, 0.5, 0.6
  Platform APIs:
    Deprecated: (none)
    Supported: 0.3, 0.4, 0.5, 0.6

Run Images:
  index.docker.io/paketobuildpacks/run:base-cnb
  gcr.io/paketo-buildpacks/run:base-cnb

• Can you provide a sample app or relevant configuration (buildpack.yml, nginx.conf, etc.)?
  A single apt install <some_dependency> in the build binary.

Checklist

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

Inside a Ruby on Rails 6 app, the builder:base only detected node/yarn attributes:

$ pack build my-app --builder paketobuildpacks/builder:base
base: Pulling from paketobuildpacks/builder
Digest: sha256:06cf6d6098ef9bab49a896ce7d5ae4585c56caaf702909d8af7b389ea75751d1
Status: Image is up to date for paketobuildpacks/builder:base
base-cnb: Pulling from paketobuildpacks/run
Digest: sha256:155ee4b4389fa88b8b9bd5444601417218b3da44e491b1aad8c8b6c2365e7909
Status: Image is up to date for paketobuildpacks/run:base-cnb
===> DETECTING
paketo-buildpacks/node-engine  0.1.2
paketo-buildpacks/yarn         0.0.2
paketo-buildpacks/yarn-install 0.2.0
paketo-buildpacks/yarn-start   0.0.2

Perhaps relates to paketo-buildpacks/ruby#464

The README in this repo is sparse. I would love to see this expanded out with more details about the builder! These could be things like supported languages, the build and run image, the mixins potentially.

Context
Once we finish up the changes proposed in https://github.com/paketo-buildpacks/builder/issues/31, we should start publishing (tagging) each version of the Base Builder. This will allow users to pack build apps using a specific version of the builder, and eventually allow us to publish Github releases and release notes.

Proposal
We should tag each Base Builder release with as follows gcr.io/paketo-buildpacks/builder-tmp:<VERSION>-base

Initial versioning should be 0.1.0 and bump the patch version whenever the builder changes. This will eventually allow us to get rid of the concourse jobs that currently publish builders and ensure a smooth transition for users.

Describe the Enhancement

As a customer I want to be able to have Full Builder / Base Builder / Tiny Builder available for linux/arm64.

As I can see at docker hub all images are only available for linux/amd64 (os/arch). Example: https://hub.docker.com/r/paketobuildpacks/builder/tags

There are already solutions for linux/arm64 (os/arch). Example: https://hub.docker.com/r/dashaun/java-native-builder-arm64/tags

Possible Solution

Change the "release" GitHub-Actions so that also Images for linux/arm64 are published at the same tag for a different arch, so that consumers can pull it like docker pull --platform linux/arm64 paketobuildpacks/builder:latest like in spring-boot-maven-plugin.

Maybe the tomls can somehow be parameterized in those Actions and a loop can be created to publish each arch.

Motivation

As a Spring Boot 3 user I want to be able to create arm64 native images officially maintained by paketo like in this maven example:

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
    <configuration>
        <image>
            <builder>paketobuildpacks/builder:tiny</builder>
            <env>
                <BP_NATIVE_IMAGE>true</BP_NATIVE_IMAGE>
            </env>
        </image>
    </configuration>
    <executions>
        <execution>
            <id>process-aot</id>
            <goals>
                <goal>process-aot</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Currently I have to change the builder to <builder>dashaun/java-native-builder-arm64</builder>

Note: I hope I didn't miss a ticket which is already opened for that topic.
Note2: This ticket might be not created at the right repository as it belongs to all builders.

Background

In paketo-buildpacks/github-config#302 we added a check when we push buildpackages to verify the buildpack version and the release tag. This is helpful since we manually cut releases, and the versions can easily get mismatched if we cut a minor or major release instead of a patch. Without this check, a buildpackage with mismatched versions might get pushed to Dockerhub which is less than ideal.

Issue

Add a check for version discrepancy to the push-image workflow, since we don't have this workflow in our common github-config repository.

I am using paketo build packs with Spring Boot for Native Container Images.
While it works in general, there is a requirement for Docker to have access to either curl or wget inside the base image.
Unfortunately neiter :tiny nor :base supports this.
And we have to use :full which is 700MB big.

So it would be nice that at least :base contains curl out of the box

Create Release workflow failed.

Once the Ruby Buildpack has been promoted to an official Paketo Buildpack, we should add it to the Paketo Base Builder so that users can easily consume the buildpack.

Update Builder TOML workflow failed.

All of our Spring Boot image builds stopped working today. We tracked it down to the use of paketobuildpacks/builder:base. The process hangs indefinitely on the "Running creator" step as of 1.0.87-base. The same problem occurs with 1.0.88-base. Manually configuring Spring Boot to use 1.0.86-base fixes the problem.

Command: mvn clean spring-boot:build-image
Environment: GCP Cloud Build
Spring Boot Versions: 2.4.3 and 2.4.4
Log:

Step #1 - "build": Downloaded from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-classworlds/2.6.0/plexus-classworlds-2.6.0.jar (53 kB at 102 kB/s)
Step #1 - "build": Downloaded from central: https://repo.maven.apache.org/maven2/org/codehaus/plexus/plexus-utils/3.2.1/plexus-utils-3.2.1.jar (262 kB at 497 kB/s)
Step #1 - "build": [INFO] Replacing main artifact with repackaged archive
Step #1 - "build": [INFO] 
Step #1 - "build": [INFO] <<< spring-boot-maven-plugin:2.4.3:build-image (default-cli) < package @ XXX <<<
Step #1 - "build": [INFO] 
Step #1 - "build": [INFO] 
Step #1 - "build": [INFO] --- spring-boot-maven-plugin:2.4.3:build-image (default-cli) @ XXX ---
Step #1 - "build": [INFO] Building image 'gcr.io/XXX/XXX:develop'
Step #1 - "build": [INFO] 
Step #1 - "build": [INFO]  > Pulling builder image 'docker.io/paketobuildpacks/builder:base' 6%
Step #1 - "build": [INFO]  > Pulling builder image 'docker.io/paketobuildpacks/builder:base' 15%
Step #1 - "build": [INFO]  > Pulling builder image 'docker.io/paketobuildpacks/builder:base' 21%
Step #1 - "build": [INFO]  > Pulling builder image 'docker.io/paketobuildpacks/builder:base' 21%
Step #1 - "build": [INFO]  > Pulling builder image 'docker.io/paketobuildpacks/builder:base' 24%
Step #1 - "build": [INFO]  > Pulling builder image 'docker.io/paketobuildpacks/builder:base' 28%
Step #1 - "build": [INFO]  > Pulling builder image 'docker.io/paketobuildpacks/builder:base' 36%
Step #1 - "build": [INFO]  > Pulling builder image 'docker.io/paketobuildpacks/builder:base' 44%
Step #1 - "build": [INFO]  > Pulling builder image 'docker.io/paketobuildpacks/builder:base' 51%
Step #1 - "build": [INFO]  > Pulling builder image 'docker.io/paketobuildpacks/builder:base' 56%
Step #1 - "build": [INFO]  > Pulling builder image 'docker.io/paketobuildpacks/builder:base' 60%
Step #1 - "build": [INFO]  > Pulling builder image 'docker.io/paketobuildpacks/builder:base' 64%
Step #1 - "build": [INFO]  > Pulling builder image 'docker.io/paketobuildpacks/builder:base' 100%
Step #1 - "build": [INFO]  > Pulled builder image 'paketobuildpacks/builder@sha256:f9035642ff8934e1eaf54661ef4975efd5050ab8b38315cc64434ca8a5d771e5'
Step #1 - "build": [INFO]  > Pulling run image 'docker.io/paketobuildpacks/run:base-cnb' 100%
Step #1 - "build": [INFO]  > Pulled run image 'paketobuildpacks/run@sha256:0bf521429c5fac06616ef542da735f9e34c4997cc5d5987242eb7199b04ac923'
Step #1 - "build": [INFO]  > Executing lifecycle version v0.11.0
Step #1 - "build": [INFO]  > Using build cache volume 'pack-cache-3482662deee0.build'
Step #1 - "build": [INFO] 
Step #1 - "build": [INFO]  > Running creator

Every time we republish the gcr.io/paketo-buildpacks/builder:base tag we should republish gcr.io/paketo-buildpacks/builder:base-platform-api-0.3 to point at the same image.

Released 2.3.x versions of the Spring Boot Maven and Gradle plugins depend on this tag. We should keep it updated with the latest buildpacks. Now that lifecycle supports Multiple platform APIs it is safe to assume that the latest lifecycle supports Platform API 0.3.

What happened?

Hitting rate limits from docker.io using buildpack

• What were you attempting to do?
  Run buildpack very frequently

• What did you expect to happen?
  No rate limits hit

• What was the actual behavior? Please provide log output, if possible.
  Because the run image is set to "index.docker.io/paketobuildpacks/run:base-cnb" it is causing an error in my pipelines, because of the frequency it is being used.

Logs included:

ERROR: failed to build: fetching lifecycle image: Error response from daemon: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit

Build Configuration

• What platform (pack, kpack, tekton buildpacks plugin, etc.) are you
  using? Gitlab with CNB

• What buildpacks are you using? paketobuildpacks/builder:0.1.83-base

• What builder are you using? If custom, can you provide the output from pack inspect-builder <builder>? paketobuildpacks/builder:0.1.83-base

Checklist

• I have included log output.
• The log output includes an error message.
• I have included steps for reproduction.

Currently, the order groups for the full builder are those listed in the builder.toml.

However, there is an accepted RFC in the builder repo that indicates that the buildpacks should be in a different order.

The builder order should be updated to reflect the accepted RFC.

Note
We should wait until the work for the Full Builder is complete (https://github.com/paketo-buildpacks/builder/issues/27) before picking this up, so we can re-use the actions.

Current Situation

Paketo users frequently ask to be able to see the builder.toml files used to create any of the Paketo Builders so that they could create custom builders easily.

Right now builders are created in a concourse task that creates a temporary builder.toml and uses it in pack create-builder. The builder.toml file isn't saved anywhere and is lost after the task ends.

Proposal

We should check in a builder.toml for each version of the base builder. When that version of the builder gets released, we should publish a release and tag with repo with the correct version. Because we have three different builders that are released separately, I believe this means we need to split the base builder out into its own new repo.

Note For the time being, we should just publish to a temporary location so that we could verify that everything works. Publish to the following path: gcr.io/paketo-buildpacks/builder-tmp:base

Motivation

We should always strive for strict versioning and reproducibility, and right now we have neither. Right now it's very difficult to tell what version of what buildpack are in each builder, and this will make that very clear. All you would have to do is look at the repo at the right tag. Also, if you wanted to rebuild the builder, you could simply check the repo out the the correct repo.

Proposed Implementation

I think we can follow the same actions flow as we do to update implementation buildpacks in their respective language families. So, in this case, when a language family is updated, it will send a dispatch event its respective builders, which will create a pull request against themselves.

Currently, we test new versions of the builder.toml in the base builder with smoke tests that pack create-builder and then pack build a set of sample apps. (See test-pull-request and create-release workflows for examples.) These smoke tests are slow, not parallelized, and do not cover all of the language families the builders support.

Each builder should have smoke tests that test each of the language families within the builder. The tests should check that the expected buildpack is the one that passed detection (e.g. Ruby buildpack detects on a rackup sample app) and that the built app image starts correctly.

By implementing the tests with occam, we get the benefit that the tests can be run in parallel so we'd end up with better test coverage without slowing down our workflows.

Context
Once we've implemented https://github.com/paketo-buildpacks/builder/issues/31 and https://github.com/paketo-buildpacks/builder/issues/32, and we've verified that the changes look good, we should swap over from the temporary GCR path to the official Dockerhub and location for the Base Builder.

Builders should get published to the following location:
paketobuildpacks/builder:base (for the latest version)
paketobuildpacks/builder:<VERSION>-base (for specific versions)
gcr.io/paketo-buildpacks/builder:base (for the latest version)
gcr.io/paketo-buildpacks/builder:<VERSION>-base (for the latest version)
cloudfoundry/cnb:base (for the latest version)
cloudfoundry/cnb:<VERSION>-base (for specific versions)

Notes

• This is a little different from the Full builder work. For backwards compatibility reasons, we'll have to continue publishing Base Builder to both GCR and Dockerhub
• At this point, we can get rid of the Concourse jobs for the Base builder.

Hello,
We switched from base-builder version 0.3.182 to 0.3.207 to build docker images for a spring-boot project (using the spring-boot maven plugin to interact with Paketo Buildpacks) and faced some regressions regarding memory.
The considered project is a webflux spring boot 2.7.9 project and we use https://github.com/paketo-buildpacks/datadog to enable datadog monitoring of this api.
We used the produced Docker image to deploy this api on AWS EKS.

When using 0.3.207, we can see that the total memory used by the container gradually increases until it reaches the maximum memory available and pods begin restarting.

The amount of heap and non heap memory appears to be quite stable :

With builder 0.3.182, the evolution of the memory used by the container is more linear :

We try to analyze the differences between the two versions of the builder and it seems that amongst several upgrades of inner components, one of the main change is the switch from the datadog agent 1.6.0 to 1.10.0.

We also realize that there is an issue opened on https://github.com/DataDog/dd-trace-java, DataDog/dd-trace-java#4883 which seems to be related to our issue.
Datadog also released the version 1.12.1 few days ago.

Is there any known regressions between those 2 versions?
From your point of view, could those memory issues be related to the Java datadog agent?
If the memory issue is related to datadog agent, is it planned to use the new 1.12.1?
Thank you in advance for you help.

I had customized a runImage to chage locale to zh_CN.UTF-8 and timezone to Asia/Shanghai ,however,those changes did't work as wish

Expected Behavior

chage locale to zh_CN.UTF-8 and timezone to Asia/Shanghai, timestamp equal to current timezone not 'default'

I' a Chinese developer and want to build a runImage which suite for chinese language.

Current Behavior

locale was unseted, timezone do be chagned but timestamp still did't match it

Possible Solution

Steps to Reproduce

1. here is my Dockerfile

FROM ubuntu:bionic

LABEL io.buildpacks.stack.id="io.buildpacks.stacks.bionic"
ARG packages=' curl jq '
ARG package_args='--allow-downgrades --allow-remove-essential --allow-change-held-packages --no-install-recommends'

RUN  sed -i "s@http://.*archive.ubuntu.com@http://repo.huaweicloud.com@g" /etc/apt/sources.list && \
     sed -i "s@http://.*security.ubuntu.com@http://repo.huaweicloud.com@g" /etc/apt/sources.list

RUN echo "Package: $packages\nPin: release c=multiverse\nPin-Priority: -1\n\nPackage: $packages\nPin: release c=restricted\nPin-Priority: -1\n" > /etc/apt/preferences

RUN echo "debconf debconf/frontend select noninteractive" | debconf-set-selections && \
  export DEBIAN_FRONTEND=noninteractive && \
  apt-get -y $package_args update && \
  apt-get -y $package_args upgrade && \
  apt-get -y $package_args install locales language-pack-zh-hans language-pack-zh-hant language-pack-zh-hans-base && \
  locale-gen zh_CN.UTF-8 && \
  # update-locale LANG=zh_CN.UTF-8 LANGUAGE=zh_CN.zh:en_US:en LC_ALL=zh_CN.UTF-8 && \
  echo -e "export LANG=zh_CN.UTF-8\nexport LANGUAGE=zh_CN.zh:en_US:en\nexport LC_ALL=zh_CN.UTF-8" >> /etc/profile && \
  apt-get -y $package_args install tzdata && \
  ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && \
  echo "Asia/Shanghai" /etc/timezone && \
  apt-get -y $package_args install $packages && \
  find /usr/share/doc/*/* ! -name copyright | xargs rm -rf && \
  rm -rf \
    /usr/share/man/* /usr/share/info/* \
    /usr/share/groff/* /usr/share/lintian/* /usr/share/linda/* \
    /var/lib/apt/lists/* /tmp/* /etc/apt/preferences

# remove /etc/os-release first as the test framework does not follow symlinks
RUN rm /etc/os-release && cat /usr/lib/os-release | \
    sed -e 's#PRETTY_NAME=.*#PRETTY_NAME="Paketo Buildpacks Base Bionic"#' \
        -e 's#HOME_URL=.*#HOME_URL="https://github.com/paketo-buildpacks/bionic-base-stack"#' \
        -e 's#SUPPORT_URL=.*#SUPPORT_URL="https://github.com/paketo-buildpacks/bionic-base-stack/blob/main/README.md"#' \
        -e 's#BUG_REPORT_URL=.*#BUG_REPORT_URL="https://github.com/paketo-buildpacks/bionic-base-stack/issues/new"#' \
  > /etc/os-release && rm /usr/lib/os-release

docker build -t docker.myserver.com:5000/tianming2019/run:cn .

2. create a spring-boot application
   link: https://start.spring.io/#!type=maven-project&language=java&platformVersion=2.7.6&packaging=war&jvmVersion=11&groupId=com.example&artifactId=demo&name=demo&description=Demo%20project%20for%20Spring%20Boot&packageName=com.example.demo&dependencies=web,actuator
3. change pom.xml

<plugin>
                                <groupId>org.springframework.boot</groupId>
                                <artifactId>spring-boot-maven-plugin</artifactId>
                                <executions>
                <execution>
                    <goals>
                        <goal>build-image</goal>
                </goals>
                <configuration>
                        <docker>
                               <!-- another host which  running docker too -->
                                <host>tcp://192.168.10.116:2375</host>
                        </docker>
                        <image>
                                <runImage>docker.myserver.com:5000/tianming2019/run:cn</runImage>
                                <bindings>
                                     <!-- used to modify jdk and syft download url -->
                                    <binding>proxy-volume:/platform/bindings/dependency-mapping:ro</binding>
                            </bindings>
                            <!--<verboseLogging>true</verboseLogging> -->
                            <buildpacks>
                                    <!-- <buildpack>docker://gcr.io/paketo-buildpacks/java:8.2.0</buildpack> -->
                                    <!-- <buildpack>paketo-buildpacks/[email protected]</buildpack>
                                    <buildpack>paketo-buildpacks/[email protected]</buildpack>
                                    <buildpack>paketo-buildpacks/[email protected]</buildpack>
                                    <buildpack>paketo-buildpacks/[email protected]</buildpack>
                                    <buildpack>paketo-buildpacks/[email protected]</buildpack> -->
                                    <!-- <buildpack>urn:cnb:builder:paketo-buildpacks/java</buildpack> -->
                                <!-- <buildpack>urn:cnb:registry:paketo-buildpacks/health-checker</buildpack> -->
                                <!-- <buildpack>urn:cnb:builder:paketo-buildpacks/health-checker</buildpack> -->
                                <!-- <buildpack>paketo-buildpacks/[email protected]</buildpack> -->
                                <!-- <buildpack>paketo-buildpacks/health-checker</buildpack> -->
                                <!-- <buildpack>/platform/bindings/dependency-mapping/health-checker/</buildpack> -->
                                <!-- <buildpack>file:///home/cnb/health-checker.tar.gz</buildpack> -->
                            </buildpacks>
                            <env>
                                    <BP_JVM_TYPE>JDK</BP_JVM_TYPE>
                                    <BP_JVM_VERSION>11.*</BP_JVM_VERSION>
                            </env>
                         </image>
                        </configuration>
                </execution>
            </executions>
                        </plugin>

Motivations

default behavior don't meet Chinese region well, I have to build my own runImage to change locale and timezone at least

still unknown is there any other changes must to do