base-builder's People
Forkers
fg-j thitch97 eagle-io youmier darylrobbins tisvictress robdimsdale brushmate pro1515151515 exnadella ratanajangir bochengdong loyalswallowbase-builder's Issues
Rails app only detected node/yarn
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
Add Ruby Buildpack to Base Builder
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.
Apple Silicon (M1) support for all paketo-buildpacks Builder
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.
Spring Boot Build-Image no longer works on GCP Cloud Build
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
customized runImage does not work as wish
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
- 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 .
- 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 - 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
Update builder order to conform to Paketo RFC 42
Per RFC 0042, we should re-order the builder.
This will constitute a minor version bump of the builder.
Source with node_modules fails to detect Java application
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
...
The builder.toml for every released Base builder should be checked into a repo
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.
Support to install dependencies using apt using base-builder as builder
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 singleapt 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.
Base builder should have occam smoke tests
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.
Check for version discrepancy when pushing image
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.
Base builder order should match Builder RFC #1
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.
Failure: Update Builder TOML workflow
Update Builder TOML workflow failed.
Base Builder should get published to official Dockerhub AND GCR locations
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.
Build via spring-boot-maven-plugin failing with the default base builder version (same as 0.2.70-base) since 27th May
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.
Start publishing release notes for each version of the Base Builder
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]
Builder RFC #3 - Automate builder release
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
README Improvements
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.
Failure: Create Release workflow
Create Release workflow failed.
Start publishing versioned Base builder releases to GCR
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.
Run image in docker.io causing rate limit issue
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.
Test builder using Paketo samples tests
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.
Keep `:base-platform-api-0.3` in sync with `:base`
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.
Add support for curl
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
Add custom folders during paketo build
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
Memory issue with base-builder 0.3.207
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.
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.