Paketo Buildpacks
Replies: 21 comments 25 replies
-
|
I would like to see the Node.js language family to graduate to v1.0. |
Beta Was this translation helpful? Give feedback.
-
|
For this specific topic, you can follow along with the tracking issue here: paketo-buildpacks/nodejs#680 |
Beta Was this translation helpful? Give feedback.
-
|
Currently looking into the 2022 roadmap discussion as a source for inspiration: Has Java RFC 0007 been implemented in the meantime? If not, should it be? |
Beta Was this translation helpful? Give feedback.
-
|
The RFC was approved, but not implemented. I am still in favor of it, but I think it's slipped in priority because it will be a decent amount of work and we haven't had a lot of requests for it. tl;dr - this RFC is to adjust the memory calculator to work better when less than 1G of RAM is given. If folks are interested in this being prioritized, please up-vote this comment. |
Beta Was this translation helpful? Give feedback.
-
|
Separating buildpacks and dependency management. See Dan Mikusa’s work in progress proposal. Note: We've decided in 2022 that we won't push for it, as there are other means to reach our goals. But if there would be pull from the community, we would likely be able to help. |
Beta Was this translation helpful? Give feedback.
-
|
Has the Remove Stacks & Mixins RFC been tackled or at least planned yet? Note: If we go for it, I would like to additionally see less use of the |
Beta Was this translation helpful? Give feedback.
-
|
Should we merge |
Beta Was this translation helpful? Give feedback.
-
|
We might want to consider trying to push for a libcnb v2 release this coming year. It is somewhat out of our control as it's upstream, but if we ever want to get to a single library that is the first step. The v2 libcnb library is being modified so that it can be the base for both packit and libpack, which means the core buildpack spec implementation will be the same for both. What's left after that in packit and libpak will be conventions/opinions held by those libraries. |
Beta Was this translation helpful? Give feedback.
-
|
I would like to see the next step in regard to ARM64 images. In 2022, we took some steps, making it possible for users to build their own ARM64 images and that resulted in an unofficial ARM64 image for Java users. I'd like to see more in 2023. I'd like to see at least one Paketo ARM64 stack available (build and run images). The base would probably be a good place to start as it supports a decent number of buildpacks. If we could get tiny & full too, that would be awesome. That would take some of the work away from creating your own ARM64 images. I don't think it would require upstream tool changes either, so it seems feasible. |
Beta Was this translation helpful? Give feedback.
-
|
Please, please support ARM. I don't trust software I can't preflight on my own machines and ARM has been around in some incarnation or another for years, most recently with apple's m1. |
Beta Was this translation helpful? Give feedback.
-
|
I went to the AWS re:Invent conference this year and they're really pushing their new Arm64 based Graviton3 processors for the benefit of higher performance and lower cost. We're planning to move our Spring Boot based AWS workloads over to ARM in 2023. Having paketo-buildpacks capable of producing ARM images would be tremendously helpful with that migration. |
Beta Was this translation helpful? Give feedback.
-
|
Not sure, but would it make sense to introduce stacks for 22.10, 23.04 and 23.10 as a preparation for quick adoption of 24.04? Like we could treat it similarly to e.g. non-LTS versions of Java and Node.js. |
Beta Was this translation helpful? Give feedback.
-
|
I believe auto-generated reference docs are already on our 2022 Roadmap / the core team has discussed doing this recently. I wanted to capture my desire for this here as well. |
Beta Was this translation helpful? Give feedback.
-
|
I'd like to finally align on a path forward for debug logging across the project in both Java/non-Java buildpacks. |
Beta Was this translation helpful? Give feedback.
-
|
Question for clarification. Are you looking to see RFC 0027 implemented? Or is this more than what's covered in that RFC? |
Beta Was this translation helpful? Give feedback.
-
|
A step further than what's in that RFC, actually aligning on a standard for what should be included in debug logs. Right now, some of the non-Java buildpacks have debug logs, but they're very inconsistent in the content they provide. I'd love to have a more uniform experience |
Beta Was this translation helpful? Give feedback.
-
|
Solve the layer limit problem in the Paketo Builders. Probably by squashing layers in some way like per language family or composite buildpack. However, we could also consider breaking away from the all-in-one builder and exploring language-specific builders instead (do feel free to comment here with thoughts on this). This is presently stifling things the projects would like to do, such as adding the APM-related buildpacks to the builders or adding more JVM providers to the default Java composite buildpack. |
Beta Was this translation helpful? Give feedback.
-
|
What is the limit, where is it being hit? I like the idea of language-specific builders. In all of the places that I use buildpacks, I have the option to add multiple, and change the order, etc. What are some of the reasons to continue supporting the all-in-one builder approach? |
Beta Was this translation helpful? Give feedback.
-
|
I really like the idea of language-specific builders. |
Beta Was this translation helpful? Give feedback.
-
|
There's a hard limit of 127 layers. It is a Linux kernel limit, so it cannot be changed. The rationale for an all-in-one builder are a.) convenience, you don't have to think about it, it's always the same one, b.) discoverability, The language-specific builders, IMO, would be more of a power-user feature. If you're familiar with buildpacks and know what buildpacks you need, a language-specific builder would be more streamlined. Fewer layers, it would download faster, and take up less space, but still give you the functionality you need. |
Beta Was this translation helpful? Give feedback.
-
|
Agree on the builders. While I also like language specific builders, it sounds like an optimization for a later stage. For first user experience, if we can shrink the full builder to make that experience a bit more snappy, that would be something. Not sure if there's low hanging fruit. |
Beta Was this translation helpful? Give feedback.
-
|
I would be interested in providing buildpacks to create dev images. i.e. images that can be used as a vscode dev container for eg. |
Beta Was this translation helpful? Give feedback.
-
|
Move dependencies to upstream binaries wherever possible. Currently the Java buildpacks try to directly include upstream dependencies wherever possible. The other buildpacks however seen to rely on the dependencies served by the paketo dep server. In some cases, this is required (for eg. python and ruby interpreters) but there are cases where this is not necessary. In general I would like to see the entire paketo buildpack distribution/dep-server potentially updated so that the dependencies we custom build are more easily discoverable from the relevant buildpack and we upstream sources. |
Beta Was this translation helpful? Give feedback.
-
|
@samj1912 the good news on this one is that we're almost done moving away from the dep-server already, moving a model that A. tries to use upstream dependencies where possible, and B. has discoverable code alongside the buildpack itself for version discovery, metadata generation, and compilation (in cases where we have to do it). It was a huge undertaking, but we have an issue here for this: paketo-buildpacks/rfcs#236 Making dependencies more customizable is a different story though, and I think that would be great to see. That connects back to https://github.com/orgs/paketo-buildpacks/discussions/58#discussioncomment-4344953 |
Beta Was this translation helpful? Give feedback.
-
|
Support for RHEL stacks. |
Beta Was this translation helpful? Give feedback.
-
|
For clarification: Is that a request to test with a RHEL stack or a request for Paketo to provide one? |
Beta Was this translation helpful? Give feedback.
-
|
I guess if there are tests with a RHEL stack, Paketo might as well provide one. I am more interested in having RHEL support for buildpacks like ruby, python, nginx etc. But I primarily care about the above buildpacks working with a RHEL stack, not necessarily one being provided. |
Beta Was this translation helpful? Give feedback.
-
|
PHP buildpack 🫣, and smaller images across the board. |
Beta Was this translation helpful? Give feedback.
-
|
Sign all buildpacks using cosign and generate an SBOM for them. |
Beta Was this translation helpful? Give feedback.
-
|
A buildpack with those tools onboard to build a fully static build executable (e.g including the GLIBC and not needed at runtime). |
Beta Was this translation helpful? Give feedback.
-
|
A small one; Support Structured Log Format |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I would like to know the plans for Compiling a native application in a manual way, it is possible without any problem: <plugin>
<groupId>org.graalvm.buildtools</groupId>
<artifactId>native-maven-plugin</artifactId>
<configuration>
<buildArgs>
<buildArg>--static</buildArg>
<buildArg>--libc=musl</buildArg>
</buildArgs>
</configuration>
</plugin>But using <plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<image>
<buildpacks>
<buildpack>gcr.io/paketo-buildpacks/bellsoft-liberica:9.10</buildpack>
<buildpack>gcr.io/paketo-buildpacks/java-native-image</buildpack>
</buildpacks>
<env>
<BP_NATIVE_IMAGE>true</BP_NATIVE_IMAGE>
<BP_JVM_VERSION>17</BP_JVM_VERSION>
<BP_NATIVE_IMAGE_BUILD_ARGUMENTS>-J-Xmx6000m --static --libc=musl</BP_NATIVE_IMAGE_BUILD_ARGUMENTS>
<BP_BINARY_COMPRESSION_METHOD>upx</BP_BINARY_COMPRESSION_METHOD>
<pullPolicy>IF_NOT_PRESENT</pullPolicy>
</env>
</image>
</configuration>
</plugin>Many thanks in advance |
Beta Was this translation helpful? Give feedback.
-
|
This image was explained in Devoxx BE 2022 here:
But reviewing the official documentation, I was not able to get further details. If you compile the image without buildpacks, it works: <plugin>
<groupId>org.graalvm.buildtools</groupId>
<artifactId>native-maven-plugin</artifactId>
<configuration>
<buildArgs>
<buildArg>--static</buildArg>
<buildArg>--libc=musl</buildArg>
</buildArgs>
</configuration>
</plugin> |
Beta Was this translation helpful? Give feedback.
-
|
So the pom.xml native profile does not work with Also there is an issue dependent on the native-image tag/version Did anyone created a buildpack that does the job? Then i tried out with "pure" native-image approach .. using but i always stops with error messgae musl-gcc is really not (expected) on the path but gcc via env var CC and also x86_64-linux-musl-gcc is like expected With debug options... Then i copied Also see oracle/graal#4645 I have tried arounds and found a working solution - still figuring out what is the key (might be that it doesn't work for NIK and or you have to make musl yourself) |
Beta Was this translation helpful? Give feedback.
-
|
Yes, you can see my pipeline creating spring native apps with musl support but not using buildpacks:
To learn the way, I reviewed the examples from: |
Beta Was this translation helpful? Give feedback.
-
|
There is an issue with nik I expect gcr.io/paketo-buildpacks/bellsoft-liberica:9.10 would then have the same issue after we would overcome missing (detector) musl support in gcr.io/paketo-buildpacks/java-native-image. realated mus support PR's
Where bellsoft-liberica seems define stack support for ubuntu they also seem to provide alpine with musl onbaord but which is not used as stack in buildpacks.- see https://assets.ctfassets.net/oxjq45e8ilak/3mzaJh8QxOz9VDFWeYmH01/2bdb741806000213ca775a2d4183eb28/Alpine_NIK_en_Joker.pdf |
Beta Was this translation helpful? Give feedback.
-
|
From my side, I didn´t test any nik release at the moment. |
Beta Was this translation helpful? Give feedback.
-
|
Document the process for building offline images. It is possible to build offline images (where all of the buildpack dependencies are bundled into the image), however, I do not believe we currently have this process documented (100% sure for Java buildpacks, not sure for other buildpacks). It should be a small matter to document this process and the tools. |
Beta Was this translation helpful? Give feedback.
-
|
Should we put an aligned and streamlined dependency update and release process on the roadmap? I've got mainly "using renovate for updates" in mind, but there might be more process things that would benefit from putting some effort in... |
Beta Was this translation helpful? Give feedback.
-
|
Thanks to everyone that posted feedback & upvoted issues! It is appreciated. We are closing this discussion to digest your feedback and will post a blog post with the summary and our 2023 roadmap shortly. |
Beta Was this translation helpful? Give feedback.
-
With 2022 fast approaching its end, we want to take the time to gather ideas for the next year's roadmap. 2022 was a super productive year for the project and we got a lot done.
What do you think the Paketo Buildpacks project should be working on in 2023? Check out last years discussion and roadmap for inspiration. Let us know by commenting and upvoting items below.
After the new year, the Steering Committee will synthesize this discussion into a set of themes for the roadmap in 2023. We look forward to hearing what great new things Paketo Buildpacks should be doing next year!
Thank you!
Beta Was this translation helpful? Give feedback.
All reactions