buildpacks / samples Goto Github PK

Getting the following error:

pack build hello-java-img --buildpack from=builder --buildpack ../buildpack-samples/buildpacks/hello-world
ERROR: failed to build: validating stack mixins: buildpack samples/[email protected] does not support stack io.paketo.stacks.tiny

Using a simple Java app to test. The same app without the sample builder builds successfully with the tiny stack.

Can the samples be updated to support the tiny stack please?

We should add a simple sample to uses libbuildpack, or convert one of the existing samples to use libbuildpack for educational purposes.

As originally reported here: buildpacks/docs#132

As a user, when there is a problem downloading an artifact I expect there to be a useful error.

In the README files for packages/hello-universe and packages/hello-universe-windows, it states:

pack create-package cnbs/sample-package:hello-universe --config package.toml

This should be pack package-buildpack ...

See related PR for fixtures to demonstrate build image extension: #128

We could update the curl extension to install curl instead of switching the run image (or do something else).

Add an env var or a property to specify the apache mavem version to be installed if not yet there ?

I'm worried that we'll have trouble keeping the example app up-to-date, but I don't think that should block this.

If we can't auto depend on latest fixes maybe we could setup a vetting process on the apps that run as part of CI as well. Something like OWASP dependency check: https://jeremylong.github.io/DependencyCheck/dependency-check-gradle/index.html

Originally posted by @jromero in #35 (comment)

[PLACEHOLDER]

Issue created for tracking purposes

During our retro we identified that lots of samples don't address real use-cases and need to be updated.

As an improvement we can spend some team effort to review these samples and come out with more useful ones.

• create multi arch buildpacks
• create multi arch extentions
• create multi arch builders

[java] question : Is the name of the java stack appropriate ? As the /bin/build script will perform maven compile goal, then the name of the image should be java maven buildpack ?

Trying to pack build the ruby example in this repo and I get the following errors when trying to run it with docker run --rm -p 8080:8080 ruby-sample:

bundler: failed to load command: rackup (/layers/heroku_ruby/gems/vendor/bundle/ruby/2.5.0/bin/rackup)
OptionParser::MissingArgument: missing argument: -p
  /layers/heroku_ruby/gems/vendor/bundle/ruby/2.5.0/gems/rack-2.0.7/lib/rack/server.rb:97:in `parse!'
  /layers/heroku_ruby/gems/vendor/bundle/ruby/2.5.0/gems/rack-2.0.7/lib/rack/server.rb:333:in `parse_options'
  /layers/heroku_ruby/gems/vendor/bundle/ruby/2.5.0/gems/rack-2.0.7/lib/rack/server.rb:195:in `initialize'
  /layers/heroku_ruby/gems/vendor/bundle/ruby/2.5.0/gems/rack-2.0.7/lib/rack/server.rb:148:in `new'
  /layers/heroku_ruby/gems/vendor/bundle/ruby/2.5.0/gems/rack-2.0.7/lib/rack/server.rb:148:in `start'
  /layers/heroku_ruby/gems/vendor/bundle/ruby/2.5.0/gems/rack-2.0.7/bin/rackup:4:in `<top (required)>'
  /layers/heroku_ruby/gems/vendor/bundle/ruby/2.5.0/bin/rackup:23:in `load'
  /layers/heroku_ruby/gems/vendor/bundle/ruby/2.5.0/bin/rackup:23:in `<top (required)>'

Additional maven options should certainly be implemented as we did here [1] to support to configure :

• HTTP_PROXY
• User's settings.xml
• MAVEN MIRROR URL
• DIR of the maven module to be compiled

Question :

• Will it be possible to pass additional parameters to the mvn compile command ?
• Will a /bin/develop script be created and extended /bin/build script in order to do mvn test

[1] https://github.com/fabric8io-images/s2i/blob/master/java/images/centos/s2i/assemble

Add a mechanism to select the JDK version and distribution.

Heroku uses a system.properties file with contents like:

java.runtime.version=1.8.0_172

For more info see Heroku docs.

/cc @cmoulliard

To aid in development and experimentation for users who would like to run CNBs on Windows, we should create a minimal nanoserver-based Windows stack.

Acceptance Criteria

Given I'm targeting a Windows docker daemon
When I run ./build-stack.sh nanoserver-1809
Then the image builds
And running docker inspect cnbs/sample-stack-build:nanoserver-1809 | jq reveals the following values in the image config:

• Label io.buildpacks.stack.id = io.buildpacks.samples.stacks.nanoserver-1809
• Env var CNB_USER_ID = S-1-1-0
• Env var CNB_GROUP_ID = S-1-1-0
• Env var CNB_STACK_ID = io.buildpacks.samples.stacks.nanoserver-1809
• User is cnb
• OS is windows

And running docker inspect cnbs/sample-stack-run:nanoserver-1809 | jq reveals the following values in the image config:

• Label io.buildpacks.stack.id = io.buildpacks.samples.stacks.nanoserver-1809
• Env var CNB_USER_ID = S-1-1-0
• Env var CNB_GROUP_ID = S-1-1-0
• User is cnb
• OS is windows

CI failure from usage of image key with pack 0.5.0:

Warning: The 'image' key is deprecated. Use 'uri="docker://..."' instead.

https://github.com/buildpacks/samples/runs/1385970992?check_suite_focus=true

Add Implementation of buildpacks/rfcs#127

buildpacks/pack#1022 adds the functionality to pack to parse the description, keywords and licenses keys in a buildpack.toml. They should be added to some of the samples, in order to demonstrate how people can do them.

e.g.

[buildpack]
id = "samples/hello-world"
version = "0.0.1"
name = "Hello World Buildpack"
homepage = "https://github.com/buildpacks/samples/tree/main/buildpacks/hello-world"
descripton = "some-description"
keywords = ["something", "something-b"]
[[buildpack.licenses]]
type="MIT"
uri="https://example.com/license"

[[buildpack.licenses]]
type="MIT2"
uri="https://example.com/license"

Will it be possible to pass additional parameters to the mvn compile command?

Yes, this is possible similar to how the referenced script provides this functionally. A buildpack can take an environment variable to provide additional args. For example, MAVEN_ARGS_APPEND . This might be worth implementing here to show how it's possible.

Originally posted by @jromero in #8 (comment)

Additional Considerations

• The REAME.md for the buildpack should be updated to provide information about the new configuration.

When a new version of the lifecycle is released, we should automatically bump the version that is in the sample builders.

It looks like our GitHub actions trigger on pushes to the samples repository, but maybe we can trigger them on lifecycle releases as well.

cnbs/sample-builder:bionic currently has lifecycle version 0.7.2.

See buildpacks/docs#152 for an example of how not updating to the latest lifecycle has caused issues.

Checking the latest execution of the CI workflows in CircleCI I noticed the sample java app is not starting. see here

I tried t o reproduced the error with the following steps:

1. I built the application image using latest pack version 0.32.1

> pack build -B cnbs/sample-builder:jammy -p apps/java-maven circleci-sample
// log messages 
Successfully built image circleci-sample

2. I tried to run application using the same docker command we are running on CircleCI

> docker run -d -p 8080:8080 circleci-sample
5d7aedf1fb00652e9a9ee4ff78050fe061d0100b7ad5580714b485c97b14213d

3. The container is not running, so I checked the logs

> docker ps
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES
>  docker logs 5d7aedf1fb00652e9a9ee4ff78050fe061d0100b7ad5580714b485c97b14213d
ERROR: failed to launch: exec.d: failed to execute exec.d file at path '/layers/samples_java-maven/jdk/exec.d/jdk.sh': fork/exec /layers/samples_java-maven/jdk/exec.d/jdk.sh: exec format error

If I am not wrong the error fork/exec /layers/samples_java-maven/jdk/exec.d/jdk.sh: exec format error is thrown because the binary is not compatible with the host architecture.

Since the pack command requires a tar or tgz in order to specify a --buildpack by URL, it would be great if this repo contained the latest sample buildpacks in tar/tgz form. That way one can try out/demo using a sample buildpack without having to clone the repo.

e.g.:

pack set-default-builder gcr.io/paketo-buildpacks/builder:base
pack build my-app --buildpack from=builder --buildpack https://github.com/buildpacks/samples/tree/main/buildpacks/hello-world

Returns:
ERROR: checking format: failed to get next tar entry: archive/tar: invalid tar header

Desired behavior:
Have a tar/tgz releases available online

Create a sample buildpack using the source created from the tutorial on the website.

It's possible that jib could be incorporated into the Java buildpack, or a jib-buildpack could be created that leverages jib to create layers.

See: #3 (comment)

/cc @imjasonh

Would it be acceptable to add deploy buttons to the samples? Like both a Heroku & Cloud Run deploy button. This would be in the form of a README in https://github.com/buildpack/samples/tree/master/apps/java-maven

Side note, that Heroku Button might not support projects in subdirs. cc @jkutner

I've cloned the sample repo to Windows 10 laptop with WSL 2 (Ubuntu 20.04).

I want to make few changes to the "run" docker file and build the dotnet-framework-1809 stack images.

1. when I run build-stack.sh from Windows command prompt as below, it opens a new bash window and the windows quickly exits with some error before I can read the error message.

C:\buildpacks-windows\stacks>build-stack.sh dotnet-framework-1809

2. When I run the build-stack.sh from inside WSL 2, I get error about operation system incompatible.

Any help is appreciated!

In light of buildpacks/rfcs#173, sample applications should be created with these new buildpack constructs: App Specified Dockerfile, Hook TOML, etc.

To aid in development and experimentation for users who would like to run CNBs on Windows, we should create a minimal buildpack that can be run on Windows.

Basically, a minimal .bat hello world buildpack.

This issue have been automatically created from pull request buildpacks/rfcs#172.

When using the sample stacks with pack version 0.4.1 the following error occurs:

ERROR: invalid builder 'cnbs/sample-stack-build:alpine': builder index.docker.io/cnbs/sample-stack-build:alpine missing label io.buildpacks.builder.metadata -- try recreating builder

seems like the sample builders are missing a newly required label io.buildpacks.builder.metadata

Add a builder.toml file to the root of buildpack/samples

When I push a change to buildpack/samples master branch
Then travis builds and publishes a new packs/samples
##Notes

• should use pack create-builder and the builder.toml from the repo root
• lifecycle travis should no longer publish packs/samples

Given I have pushed a new publish tag to buildpack/lifecycle
When travis has successfully built and pushed a new packs/build image
Then the buildpack/samples travis build is triggers and a new packs/samples image is built and publish using the updated packs/build as the base image

##Questions

• as written this would imply that any changes to master are published, are we okay with that?
• do we want this build to validate that the new packs/samples image works with pack cli (e.g. pack build --path <sample-app> --no-pull succeeds) before publishing?

Problem

I tried running the Build an app example in the Buildpack docs, but hit an error while doing so. Any thoughts on how to troubleshoot would be greatly appreciated.

Steps to reproduce

• Install pack cli: brew install buildpacks/tap/pack
• Download samples: git clone https://github.com/buildpacks/samples
• Run build command: pack build sample-app --path samples/apps/java-maven --builder cnbs/sample-builder:bionic

Outcome / Stack trace

$ pack build sample-app --path samples/apps/java-maven --builder cnbs/sample-builder:bionic
bionic: Pulling from cnbs/sample-builder
e4ca327ec0e7: Already exists 
55fae2d3d3bc: Pull complete 
6faf60e5f26d: Pull complete 
3baf523e9da9: Pull complete 
22012278af40: Pull complete 
58b1e653474f: Pull complete 
357fefdf9bc9: Pull complete 
a697cc8a1d5c: Pull complete 
5c2e4179bee1: Pull complete 
c4e3bdcbb8c3: Pull complete 
04f9e5a54d38: Pull complete 
c238db6a02a5: Pull complete 
53a52c7f9926: Pull complete 
0cceee8a8cb0: Pull complete 
a302059dbdba: Pull complete 
db1bbcc47135: Pull complete 
4f4fb700ef54: Pull complete 
Digest: sha256:01b9067fe10704647b0992b56699a4e59431d1162e769706dcf5da5dfda928c8
Status: Downloaded newer image for cnbs/sample-builder:bionic
bionic: Pulling from cnbs/sample-stack-run
e4ca327ec0e7: Already exists 
55fae2d3d3bc: Already exists 
6faf60e5f26d: Already exists 
Digest: sha256:38f19fee4ffd8caafb5550da2d26687feba159528d041101ad99cc7390a0f578
Status: Downloaded newer image for cnbs/sample-stack-run:bionic
0.11.3: Pulling from buildpacksio/lifecycle
5dea5ec2316d: Pull complete 
6d75e71a489d: Pull complete 
Digest: sha256:d6c578fbdf88f2e2594d9907307b17775e648656f62e1ae810d31c804f928cf9
Status: Downloaded newer image for buildpacksio/lifecycle:0.11.3
===> DETECTING
[detector] samples/java-maven 0.0.1
===> ANALYZING
[analyzer] Previous image with name "sample-app" not found
===> RESTORING
===> BUILDING
[builder] ---> Java buildpack
[builder] ---> Installing JDK
[builder] ---> Running Maven Wrapper
[builder] qemu: uncaught target signal 11 (Segmentation fault) - core dumped
[builder] /cnb/buildpacks/samples_java-maven/0.0.1/bin/build: line 116:    60 Segmentation fault      ./mvnw clean install -B -DskipTests
[builder] ERROR: failed to build: exit status 139
ERROR: failed to build: executing lifecycle. This may be the result of using an untrusted builder: failed with status code: 51

Environment

• pack CLI: 0.21.1+git-e09e397.build-2823
• docker: Docker version 20.10.7, build f0df350
• OS: macOS 11.6 (with an Apple M1 chip)

Summary

We need to investigate if the following issue for linux on k8s applies to Windows.

Details

Multiple users have reported an issue with the use of USER <user>.

Issue: #44

From slack:

We are trying to test our deployment against the suggested PodSecurityPolicy in k8s. K8s states the following:

MustRunAsNonRoot - Requires that the pod be submitted with a non-zero runAsUser or have the USER directive defined (using a numeric UID) in the image. Pods which have specified neither runAsNonRoot nor runAsUser settings will be mutated to set runAsNonRoot=true, thus requiring a defined non-zero numeric USER directive in the container. No default provided. Setting allowPrivilegeEscalation=false is strongly recommended with this strategy.

The Docker docs say:

USER <user>[:<group>] or
USER <UID>[:<GID>]

The following PR addresses this issue for sample linux stacks: #58

At an initial glance the solution applied to linux doesn't seem to translate directly to Windows due to the fact that UID and GID are unknown and can't be preset when creating a user. (This information was provided by @micahyoung)

Acceptance

1. It is determined whether this issue applies to Windows or not.
2. If it does, a proposed solution is provided.

Having walked through the samples repository, but I couldn't know how to handle the pack build with the Rust app. Could anyone shed the light on it? Thank you very much

The stack images under cnbs/run and cnbs/build are no longer maintained by the CNB team as they are not intended for production use. Instead, we are going to create images that better denote that they are solely samples.

Action items:

• Move stacks to samples
• Publish new images from samples to docker hub denoting they are samples. eg cnbs/sample-stack-run

Post actions:

• Remove cnb/run and cnb/build images from docker hub (task created)

The overall readme for sample apps says the sample apps can be built and run with:

pack build -p apps/<APP> --builder cnbs/sample-builder:<bionic OR alpine> sample-app
After building the app you should be able to simply run it via docker run -it -p 8080:8080 sample-app. Go to localhost:8080 to see the app running.

For the dotnet sample the build step works. However, docker run fails with:

❯ docker run -it -p 8080:8080 sample-app-dotnet
ERROR: failed to launch: determine start command: when there is no default process a command is required

The sample app should be fixed so it doesn't require a start command, or the dotnet sample should have its own readme indicating the correct command to start with. I've been digging and haven't been able to figure it out yet. The usual suspects ("dotnet" "dotnet run", etc) don't work.

Here are details buildpacks/pack#1995

pack build myapp --builder cnbs/sample-builder:bionic
e81ef84a8c4f: Exists
93406247463a: Exists
ERROR: failed to build: invalid builder cnbs/sample-builder:bionic: builder index.docker.io/cnbs/sample-builder:bionic missing label io.buildpacks.builder.metadata -- try recreating builder

pack create-builder cnbs/sample-builder:bionic --builder-config builders/bionic/builder.toml --no-pull
Error: unknown flag: --builder-config
Usage:
pack create-builder --config [flags]

Examples:
pack create-builder my-builder:bionic --config ./builder.toml

Flags:
-c, --config string Path to builder TOML file (required)
-h, --help help for create-builder
--publish Publish to registry
--pull-policy string Pull policy to use. Accepted values are always, never, and if-not-present. The default is always

Global Flags:
--no-color Disable color output
-q, --quiet Show less output
--timestamps Enable timestamps in output
-v, --verbose Show more output

pack create-builder cnbs/sample-builder:bionic --builder-config builders/bionic/builder.toml --no-pull
Error: unknown flag: --builder-config
Usage:
pack create-builder --config [flags]

Examples:
pack create-builder my-builder:bionic --config ./builder.toml

Flags:
-c, --config string Path to builder TOML file (required)
-h, --help help for create-builder
--publish Publish to registry
--pull-policy string Pull policy to use. Accepted values are always, never, and if-not-present. The default is always

Global Flags:
--no-color Disable color output
-q, --quiet Show less output
--timestamps Enable timestamps in output
-v, --verbose Show more output

pack create-builder cnbs/sample-builder:bionic --config builders/bionic/builder.toml --no-pull
Error: unknown flag: --no-pull
Usage:
pack create-builder --config [flags]

Examples:
pack create-builder my-builder:bionic --config ./builder.toml

Flags:
-c, --config string Path to builder TOML file (required)
-h, --help help for create-builder
--publish Publish to registry
--pull-policy string Pull policy to use. Accepted values are always, never, and if-not-present. The default is always

Global Flags:
--no-color Disable color output
-q, --quiet Show less output
--timestamps Enable timestamps in output
-v, --verbose Show more output

pack create-builder cnbs/sample-builder:bionic --config builders/bionic/builder.toml
Warning: Command pack create-builder has been deprecated, please use pack builder create instead

4753e82d7deb: Download complete
8cc0bf7c4c3f: Download complete
ERROR: invalid run image config: stack io.buildpacks.samples.stacks.bionic from builder config is incompatible with stack from run image cnbs/sample-stack-run:bionic

pack builder create cnbs/sample-builder:bionic --config builders/bionic/builder.toml
4753e82d7deb: Exists
8cc0bf7c4c3f: Exists
ERROR: invalid run image config: stack io.buildpacks.samples.stacks.bionic from builder config is incompatible with stack from run image cnbs/sample-stack-run:bionic
pack builder create sample-builder:bionic --config builders/bionic/builder.toml
4753e82d7deb: Exists
8cc0bf7c4c3f: Exists
ERROR: invalid run image config: stack io.buildpacks.samples.stacks.bionic from builder config is incompatible with stack from run image cnbs/sample-stack-run:bionic

Message:

...
[create] Paketo Maven Buildpack 6.5.1
[create]   https://github.com/paketo-buildpacks/maven
[create]   Build Configuration:
[create]     $BP_MAVEN_BUILD_ARGUMENTS  -Dmaven.test.skip=true --no-transfer-progress package  the arguments to pass to Maven
[create]     $BP_MAVEN_BUILT_ARTIFACT   target/*.[ejw]ar                                       the built application artifact explicitly.  Supersedes $BP_MAVEN_BUILT_MODULE
[create]     $BP_MAVEN_BUILT_MODULE                                                            the module to find application artifact in
[create]     $BP_MAVEN_DAEMON_ENABLED   false                                                  use maven daemon
[create]     $BP_MAVEN_POM_FILE         pom.xml                                                the location of the main pom.xml file, relative to the application root
[create]     Creating cache directory /home/cnb/.m2
[create]   Compiled Application: Contributing to layer
[create]     Executing mvnw --batch-mode -Dmaven.test.skip=true --no-transfer-progress package
[create]       Unable to parse command line options: Unrecognized option: --no-transfer-progress
[create]
[create]       usage: mvn [options] [<goal(s)>] [<phase(s)>]
[create]
[create]       Options:
[create]        -am,--also-make                        If project list is specified, also
[create]                                               build projects required by the
[create]                                               list
[create]        -amd,--also-make-dependents            If project list is specified, also
[create]                                               build projects that depend on
[create]                                               projects on the list
[create]        -B,--batch-mode                        Run in non-interactive (batch)
[create]                                               mode (disables output color)
[create]        -b,--builder <arg>                     The id of the build strategy to
...

Issue

The pack build command reports the following error Error: image build: Unknown flag: chown

pack build --path ./ cmoulliard/snowdrop:v1.0.0.alpha1
2018/11/07 10:07:20 Pulling builder image 'packs/samples' (use --no-pull flag to skip this step)
2018/11/07 10:07:53 Selected run image 'packs/run' from stack 'io.buildpacks.stacks.bionic'
2018/11/07 10:07:53 Pulling run image 'packs/run' (use --no-pull flag to skip this step)
*** DETECTING:
2018/11/07 09:07:59 Group: Sample Node.js Buildpack: fail
2018/11/07 09:07:59 Group: Sample Java Buildpack: pass
*** ANALYZING: Reading information from previous image for possible re-use
2018/11/07 10:07:57 WARNING: skipping analyze, image not found
*** BUILDING:
*** EXPORTING:
---> Java buildpack
---> Installing JDK
Step 1/3 : FROM packs/run
---> 2adf4cd3fc67
Step 2/3 : ADD --chown=1000:1000 /workspace/app /workspace/app
Step 2/3 : ADD --chown=1000:1000 /workspace/app /workspace/app
Error: image build: Unknown flag: chown

Steps to reproduce the error

• Install latest pack version -: https://github.com/buildpack/pack/releases/tag/v0.0.5
• Create a simple Spring Boot project locally

curl http://start.spring.io/starter.zip -o demo.zip && unzip demo.zip

• Execute the build pack command

pack build --path ./ cmoulliard/snowdrop:v1.0.0.alpha1

If I try a Pack build using Pack CLI 0.30.0 and pack build --builder cnbs/sample-builder:alpine ..., I currently get the following error:

$ pack build example-basics --builder cnbs/sample-builder:alpine --trust-builder --buildpack packaged/x86_64-unknown-linux-musl/debug/libcnb-examples_basics --path examples/
alpine: Pulling from cnbs/sample-builder
...
Status: Downloaded newer image for cnbs/sample-stack-run:alpine
ERROR: failed to build: experimental features must be enabled when builder contains image extensions

eg:
https://github.com/heroku/libcnb.rs/actions/runs/6113111959/job/16591949217?pr=668#step:10:119

I was wondering whether it might be best to move the experimental extension support to a different Docker image tag until Pack CLI can support it out of the box (without needing to enable non-default features).

(Originally discussed at: https://cloud-native.slack.com/archives/C033DV8D9FB/p1694119138551089)

@ekcasey we (I) might have been a little hasty here as it seemed like a very minute change but in thinking about it I'm not sure if these buildpacks would actually support this stack ID by definition. Some buildpacks have requirements for additional manually installed packages (jq and yj).

Originally posted by @jromero in #78 (comment)

All use of the USER instruction to setup the final closing user for an image should use:

USER $CNB_USER_ID

and not:

USER cnb

The reason for this is that it ensures that the user in the image manifest is recorded as an integer user ID that can then be used by a container platform such as Kubernetes, to verify that the image will not run as the root user.

This comes up when using pod security policies in Kubernetes. By using a name for USER, the platform cannot verify what actual user ID the image would run as. This means you can't use MustRunAs for the runUser setting of a pod security policy as it will be rejected. Instead you are forced to use in the pod security policy RunAsAny which means you have a service account in the namespace which a user could then apply to run any image as root. So using a user name for USER is going to force people to configure their platform in a less secure way when using pod security policies.

The reason Kubernetes will reject the image where USER is a user name rather than an integer user ID, is that a user name which is not root is not a guarantee that it will not run as user ID 0, as the non root user name could map to user ID 0 in the /etc/passwd file, which the platform wouldn't be able to validate.

Any examples and documentation should therefore use an integer user ID for USER. In this case it can be picked up from the environment variable set from the original build argument.

Problem

Extension samples didn't work as described in tutorial: https://buildpacks.io/docs/extension-guide/create-extension/why-dockerfiles/

Issue 1: Buildpack API incompatibility when creating the builder

I followed the tutorial to set up the local env and create the builder. Got the error of Buildpack API incompatibility:

$ pack builder create localhost:5000/extensions-builder \
  --config $PWD/samples/builders/alpine/builder.toml \
  --publish
Downloading from https://github.com/buildpacks/lifecycle/releases/download/v0.15.2/lifecycle-v0.15.2+linux.x86-64.tgz
9.76 MB/9.76 MB
ERROR: validating extensions: extension samples/[email protected] (Buildpack API 0.10) is incompatible with lifecycle 0.15.2 (Buildpack API(s) 0.2, 0.3, 0.4, 0.5, 0.6, 0.7, 0.8, 0.9)

I added the following snippet to "$PWD/samples/builders/alpine/builder.toml" as a fix:

[lifecycle]
version = "0.17.0-rc.3"

Issue 2: hello-extensions buildpack didn't pass the detection

Command:

pack build hello-extensions \
  --builder localhost:5000/extensions-builder \
  --network host \
  --path $PWD/samples/apps/java-maven \
  --pull-policy always \
  --verbose

The expected behavior is that hello-extensions buildpack passes the detection but failes the build. The result I got was the detection failed.

Output:

[detector] ======== Results ========
[detector] pass: samples/[email protected]
[detector] pass: samples/[email protected]
[detector] pass: samples/[email protected]
[detector] fail: samples/[email protected]
[detector] ======== Results ========
[detector] fail: samples/[email protected]
[detector] ======== Results ========
[detector] pass: samples/[email protected]
[detector] pass: samples/[email protected]
[detector] pass: samples/[email protected]
[detector] pass: samples/[email protected]
[detector] Resolving plan... (try #1)
[detector] skip: samples/[email protected] provides unused cowsay
[detector] skip: samples/[email protected] provides unused vim
[detector] skip: samples/[email protected] provides unused curl
[detector] 1 of 4 buildpacks participating
[detector] samples/java-maven 0.0.1

Environment

• pack CLI: 0.29.0+git-95c8060.build-4209
• docker: 20.10.21
• OS: Linux 6.1.25-1rodete1-amd64