├── text ├── go │ ├── .gitkeep │ ├── 0000-template.md │ ├── 0002-dependencies.md │ ├── 0001-remove-dep.md │ ├── go-dist │ │ └── 0001-buildpack-yml-to-env-var.md │ ├── go-mod-vendor │ │ └── 0001-vendor-rearchitecture.md │ └── go-build │ │ ├── 0004-bp-go-build-ldflags.md │ │ └── 0003-buildpack-yml-to-env-var.md ├── java │ ├── .gitkeep │ ├── 0014-selecting-default-java-version.md │ ├── 0018-retire-java-azure-composite.md │ ├── README.md │ ├── 0010-rename-open-liberty-buildpack.md │ ├── 0009-datadog.md │ ├── 0002-alibaba-jdk.md │ ├── 0001-microsoft-jdk.md │ ├── 0005-clojure-tools.md │ ├── 0015-composite-draft-branch.md │ ├── 0008-add-liberty-to-java-composite.md │ ├── 0013-opentelemetry.md │ ├── 0006-oracle-jdk.md │ └── 0017-graalvm-jdk.md ├── rust │ ├── .gitkeep │ └── README.md ├── builders │ ├── .gitkeep │ ├── 0004-base-builder-is-latest.md │ ├── 0005-publish-full-builder-to-full-cf-tag.md │ ├── 0006-add-procfile.md │ ├── 0000-template.md │ └── 0001-buildpack-order.md ├── content │ └── .gitkeep ├── tooling │ ├── .gitkeep │ ├── 0000-template.md │ └── 0001-extract-jam-from-packit.md ├── utilities │ ├── .gitkeep │ ├── 0008-tini-dependency-rework.md │ ├── README.md │ ├── 0004-git-promotion.md │ ├── 0002-syft-buildpack.md │ └── 0003-git-credential-configuration.md ├── dependencies │ ├── .gitkeep │ └── rfcs │ │ ├── 0000-template.md │ │ ├── 0001-dependency-server-licenses.md │ │ └── 0002-dependency-server-purl.md ├── python │ ├── .assets │ │ ├── 0001-proposed.png │ │ └── 0001-proposed.dot │ ├── 0004-pipenv-restructure.md │ ├── 0002-cpython-buildpack-yml-to-env-var.md │ ├── 0003-pip-rearchitecture.md │ └── 0005-pip-install-rearchitecture.md ├── dotnet-core │ ├── assets │ │ ├── 0001-original.png │ │ ├── 0001-proposed.png │ │ ├── 0001-proposed.dot │ │ └── 0001-original.dot │ ├── 0000-template.md │ ├── 0002-buildpack-yml-to-env-var.md │ └── 0008-backwards-compatible-build-plan.md ├── web-servers │ ├── 0005-promote-web-servers-buildpack.md │ ├── 0006-dependencies.md │ ├── 0001-nginx-buildpack-yml-to-env-var.md │ └── 0002-httpd-buildpack-yml-to-env-var.md ├── nodejs │ ├── 0005-node-start.md │ ├── 0007-npm-install-re-architecture.md │ ├── 0009-npm-start-command.md │ ├── 0010-yarn-start-command.md │ ├── 0017-promote-ubi-nodejs-extension.md │ ├── 0002-remove-tini.md │ ├── 0015-dependencies.md │ ├── 0006-yarn-dependency.md │ └── 0008-modular-yarn-install.md ├── ruby │ ├── passenger │ │ ├── 0001-implementation.md │ │ └── 0000-template.md │ ├── rake │ │ ├── 0000-template.md │ │ └── 0001-rake-task.md │ ├── 0000-template.md │ ├── bundle-install │ │ ├── 0000-template.md │ │ └── 0001-dev-test-gems-during-build.md │ ├── 0003-buildpack-yml-to-env-var.md │ └── 0002-procfile.md ├── stacks │ ├── README.md │ ├── 0009-remove-yj.md │ ├── 0008-jammy-full-remove-ruby.md │ ├── 0001-stack-package-metadata.md │ ├── 0007-squash-stack.md │ ├── 0002-add-libz.md │ └── 0006-node-on-tiny.md ├── 0004-clojure.md ├── php │ └── 0004-dependencies.md ├── 0021-go-generate-buildpack.md ├── 0047-promote-web-servers-buildpack.md ├── 0024-utility-buildpacks-team.md ├── 0026-environment-variable-configuration-of-buildpacks.md ├── 0000-template.md ├── 0014-rust.md ├── 0023-git-buildpack.md ├── 0012-builder-subteam.md ├── 0007-buildpack-naming.md ├── 0041-direct.md ├── 0025-emeritus-status.md ├── 0043-reproducible-builds.md ├── 0059-standard-dependency-metadata-format.md ├── 0058-new-maintainer-group-process.md ├── 0000-add-ubi9-base-images.md ├── 0064-promote-ubi-builders.md ├── 0020-blog.md ├── 0052-graceful-stack-upgrades.md ├── 0008-paketo-community.md ├── 0044-disable-sbom.md ├── 0022-core-deps-governance-restructure.md ├── 0062-promote-ubi-stack.md ├── apm │ └── 0001-remove-nodejs.md ├── 0005-ruby-promotion.md ├── 0039-semantic-version-tags.md ├── 0050-buildpack-rename.md ├── 0006-web-servers.md └── 0001-repo-migration.md ├── assets ├── blog-partial.png ├── blog-share-sheet.png ├── dashboard-partial.png └── dashboard-yarn-install-tile.png ├── NOTICE └── .github └── CODEOWNERS /text/go/.gitkeep: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /text/java/.gitkeep: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /text/rust/.gitkeep: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /text/builders/.gitkeep: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /text/content/.gitkeep: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /text/tooling/.gitkeep: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /text/utilities/.gitkeep: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /text/dependencies/.gitkeep: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /assets/blog-partial.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/paketo-buildpacks/rfcs/HEAD/assets/blog-partial.png -------------------------------------------------------------------------------- /assets/blog-share-sheet.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/paketo-buildpacks/rfcs/HEAD/assets/blog-share-sheet.png -------------------------------------------------------------------------------- /assets/dashboard-partial.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/paketo-buildpacks/rfcs/HEAD/assets/dashboard-partial.png -------------------------------------------------------------------------------- /text/python/.assets/0001-proposed.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/paketo-buildpacks/rfcs/HEAD/text/python/.assets/0001-proposed.png -------------------------------------------------------------------------------- /assets/dashboard-yarn-install-tile.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/paketo-buildpacks/rfcs/HEAD/assets/dashboard-yarn-install-tile.png -------------------------------------------------------------------------------- /text/dotnet-core/assets/0001-original.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/paketo-buildpacks/rfcs/HEAD/text/dotnet-core/assets/0001-original.png -------------------------------------------------------------------------------- /text/dotnet-core/assets/0001-proposed.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/paketo-buildpacks/rfcs/HEAD/text/dotnet-core/assets/0001-proposed.png -------------------------------------------------------------------------------- /text/web-servers/0005-promote-web-servers-buildpack.md: -------------------------------------------------------------------------------- 1 | This RFC has been moved to the [top level](../0047-promote-web-servers-buildpack.md). 2 | -------------------------------------------------------------------------------- /NOTICE: -------------------------------------------------------------------------------- 1 | Copyright (c) 2020-Present CloudFoundry.org Foundation, Inc. All Rights Reserved. 2 | 3 | This project is licensed to you under the Apache License, Version 2.0 (the "License"). 4 | You may not use this project except in compliance with the License. 5 | 6 | This project may include a number of subcomponents with separate copyright notices 7 | and license terms. Your use of these subcomponents is subject to the terms and 8 | conditions of the subcomponent's license, as noted in the LICENSE file. 9 | -------------------------------------------------------------------------------- /text/python/.assets/0001-proposed.dot: -------------------------------------------------------------------------------- 1 | digraph future { 2 | cp [label="cpython"] 3 | p [label="pip"] 4 | pi [label="pip-install"] 5 | pe [label="pipenv"] 6 | pei [label="pipenv-install"] 7 | mc [label="miniconda"] 8 | ceu [label="conda-env-update"] 9 | ps [label="python-start"] 10 | 11 | p -> cp 12 | pi -> cp 13 | pi -> p 14 | pe -> p 15 | pe -> cp 16 | pei -> p 17 | pei -> pe 18 | pei -> cp 19 | ceu -> mc 20 | ps -> cp 21 | ps -> pei 22 | ps -> pi 23 | ps -> ceu 24 | } 25 | -------------------------------------------------------------------------------- /text/dotnet-core/assets/0001-proposed.dot: -------------------------------------------------------------------------------- 1 | digraph "proposed" { 2 | p_dcr [label="dotnet-core-runtime"]; 3 | p_dcs [label="dotnet-core-sdk"]; 4 | p_dca [label="dotnet-core-aspnet"]; 5 | p_dp [label="dotnet-publish"]; 6 | p_de [label="dotnet-execute"]; 7 | p_ne [label="node-engine"]; 8 | p_i [label="icu"]; 9 | 10 | p_dp -> p_dcs [color=blue]; 11 | p_de -> p_dcs [color=red]; 12 | 13 | p_dp -> p_dcr [color=blue]; 14 | p_de -> p_dcr [color=red]; 15 | 16 | p_dp -> p_ne [color=blue]; 17 | p_de -> p_ne [color=red]; 18 | 19 | p_dp -> p_i [color=blue]; 20 | p_de -> p_i [color=red]; 21 | 22 | p_dp -> p_dca [color=blue]; 23 | p_de -> p_dca [color=red]; 24 | } 25 | -------------------------------------------------------------------------------- /text/rust/README.md: -------------------------------------------------------------------------------- 1 | # Rust RFCs 2 | 3 | This directory contains RFCs that pertain to the [Rust Subteam](https://github.com/paketo-buildpacks/community/blob/main/TEAMS.md#rust-team). Please see the repo README for guidance on [project-level vs. team-level RFCs](../../README.md#project-level-vs-team-level-rfcs). 4 | 5 | ## Accepted RFCs 6 | 7 | * None 8 | 9 | ## Implemented RFCs 10 | 11 | * [0001: Paketo Community Rustup Buildpack](0001-rustup.md) 12 | 13 | ## Links 14 | 15 | * [Rust Buildpack](http://github.com/paketo-community/rust) 16 | * [Cargo Buildpack](http://github.com/paketo-community/cargo) 17 | * [Rustup Buildpack](http://github.com/paketo-community/rustup) 18 | * [Rust Dist Buildpack](http://github.com/paketo-community/rust-dist) 19 | -------------------------------------------------------------------------------- /text/builders/0004-base-builder-is-latest.md: -------------------------------------------------------------------------------- 1 | # Switch `latest` to Base Builder 2 | 3 | ## Summary 4 | 5 | `docker pull paketobuildpacks/builder` should pull the Base Builder. 6 | 7 | ## Motivation 8 | 9 | The Base stack is the best choice for most applications. As such, the `latest` tag for stacks (`paketobuildpacks/build` and `paketobuildpacks/run`) already corresponds to the base stack. 10 | 11 | Changing the `latest` tag on the Builder to Base would bring it into sync with the stacks. 12 | 13 | ## Detailed Explanation 14 | 15 | Currently, `paketobuildpacks/builder:latest` points to the latest Full builder. This should change to point to the latest Base builder. 16 | 17 | ## Rationale and Alternatives 18 | 19 | We could switch the `latest` tag in the stacks to point to Full to match the Builders. 20 | 21 | This was rejected because we think the Base stack is the best option for most applications. 22 | -------------------------------------------------------------------------------- /text/builders/0005-publish-full-builder-to-full-cf-tag.md: -------------------------------------------------------------------------------- 1 | # Publish Full Builder to `full-cf` Tag 2 | 3 | ## Summary 4 | 5 | `docker pull paketobuildpacks/builder:full-cf` should pull the Full Builder. 6 | 7 | ## Motivation 8 | 9 | The Full builder was created to replace the Full-CF builder. This would allow us to stop shipping the Full-CF builder. 10 | 11 | ## Detailed Explanation 12 | 13 | Currently, `paketobuildpacks/builder:full-cf` points to the latest Full-CF builder. This should change to point to the latest Full builder. 14 | 15 | ## Rationale and Alternatives 16 | 17 | We could send out a deprecation notice to formally deprecate the Full-CF builder and tag. 18 | 19 | We would prefer not to do this yet as it will break users who have automation relying on the `full-cf` tag. It would also require us to continue shipping the Full-CF builder during the deprecation period, which we would prefer not to do. 20 | -------------------------------------------------------------------------------- /text/nodejs/0005-node-start.md: -------------------------------------------------------------------------------- 1 | # Node Start Buildpack 2 | 3 | ## Proposal 4 | 5 | Create a buildpack that will require `node` to be in the app image and that will write a start command. 6 | 7 | ## Motivation 8 | 9 | To support users that have Node.js applications that require no external `node modules` and does not contain a `package.json`. 10 | 11 | ## Implementation 12 | 13 | Detection will pass if there is a .js file in the application source. 14 | 15 | During the build, the buildpack will write the start command `node server.js`. `server.js` was selected as the default because it is the default application name chosen by `npm start` if the user does not specify a start command. For simplicity, the initial implementation **does not** allow the user to specify a different filename for the start command. 16 | 17 | ## Source Material (Optional) 18 | 19 | [npm-start docs](https://docs.npmjs.com/cli/start.html) 20 | 21 | -------------------------------------------------------------------------------- /text/ruby/passenger/0001-implementation.md: -------------------------------------------------------------------------------- 1 | # Passenger Buildpack Implementation 2 | 3 | ## Proposal 4 | 5 | Create a Passenger implementation buildpack to allow for applications using 6 | Passenger to have an official workflow. 7 | 8 | ## Motivation 9 | 10 | Currently, there is no support for Passenger applications in the Ruby language 11 | family. With the addition of a `passenger` buildpack, users would be able to 12 | start a Passenger application server using the Ruby buildpackage. Passenger is 13 | one of the [top four most popular web 14 | servers](https://www.ruby-toolbox.com/categories/web_servers) used within the 15 | Ruby community, so support for it could cover a large number of uses case. 16 | 17 | ## Implementation 18 | 19 | Detection will pass is `passenger` is present in the `GEMFILE`. 20 | 21 | On detection, the buildpack will set the start command to be `bundle exec 22 | passenger start --port {$PORT:-3000}`. 23 | -------------------------------------------------------------------------------- /text/utilities/0008-tini-dependency-rework.md: -------------------------------------------------------------------------------- 1 | # Decide If The Tini Dependency Will Be Paketo-hosted 2 | 3 | ## Proposal 4 | 5 | The [Tini](https://github.com/paketo-buildpacks/tini/blob/main/buildpack.toml) 6 | dependency should be removed as Paketo-hosted dependencies. 7 | 8 | ## Rationale 9 | 10 | ### Tini 11 | 12 | Remove the Paketo-hosted dependency. 13 | 14 | Currently the buildpack uses a binary that is compiled and hosted by Paketo. 15 | However, the author of `tini` attaches a static binary with the releases of 16 | `tini`. These static binaries appear to be compatible with most linux 17 | distributions and are compatible with the current buildpack which can be seen 18 | in this [proof of concept 19 | PR](https://github.com/paketo-buildpacks/tini/pull/274). There are multiple 20 | methods of doing artifact verification with both a shasum and as well an 21 | armored ASCII file that can be used for PGP verification. Because of these 22 | factors we should stop hosting `tini` ourselves. 23 | -------------------------------------------------------------------------------- /.github/CODEOWNERS: -------------------------------------------------------------------------------- 1 | * @paketo-buildpacks/steering-committee 2 | text/builders/ @paketo-buildpacks/builders-maintainers 3 | text/content/ @paketo-buildpacks/content-maintainers 4 | text/dependencies/ @paketo-buildpacks/dependencies-maintainers 5 | text/dotnet-core/ @paketo-buildpacks/dotnet-core-maintainers 6 | text/go/ @paketo-buildpacks/go-maintainers 7 | text/java/ @paketo-buildpacks/java-maintainers 8 | text/nodejs/ @paketo-buildpacks/nodejs-maintainers 9 | text/php/ @paketo-buildpacks/php-maintainers 10 | text/python/ @paketo-buildpacks/python-maintainers 11 | text/ruby/ @paketo-buildpacks/ruby-maintainers 12 | text/rust/ @paketo-buildpacks/rust-maintainers 13 | text/stacks/ @paketo-buildpacks/stacks-maintainers 14 | text/tooling/ @paketo-buildpacks/tooling-maintainers 15 | text/utilities/ @paketo-buildpacks/utilities-maintainers 16 | text/web-servers/ @paketo-buildpacks/web-servers-maintainers 17 | -------------------------------------------------------------------------------- /text/builders/0006-add-procfile.md: -------------------------------------------------------------------------------- 1 | # Stand-alone Procfile buildpack in the Tiny builder 2 | 3 | ## Proposal 4 | 5 | The Procfile buildpack should be added as a stand-alone group to the Tiny 6 | builder's group orderings. 7 | 8 | ## Motivation 9 | 10 | Adding the Procfile buildpack as a stand-alone order at the end of the group 11 | ordering list would provide users that want to run pre-built binaries on the 12 | smallest base image available a supported path to do so. 13 | 14 | ## Source Material 15 | 16 | * The Procfile buildpack is alread a stand-alone buildpack in both the 17 | [Base](https://github.com/paketo-buildpacks/base-builder/blob/77f77454f74f6eb1d71c9b2d38eb9194350f66da/builder.toml#L80-L84) 18 | and the 19 | [Full](https://github.com/paketo-buildpacks/full-builder/blob/8069fea85dab14880f1dc54fcba552bb9fce3e70/builder.toml#L100-L104) 20 | builders. 21 | * The Procfile buildpack [supports the Tiny 22 | stack](https://github.com/paketo-buildpacks/procfile/blob/a36fb09721cd8fa05215333379e406e20391612f/buildpack.toml#L26-L27). 23 | -------------------------------------------------------------------------------- /text/utilities/README.md: -------------------------------------------------------------------------------- 1 | # Utilities RFCs 2 | 3 | This directory contains RFCs that pertain to the [Utilities Subteam](https://github.com/paketo-buildpacks/community/blob/main/TEAMS.md#utilities-team). Please see the repo README for guidance on [project-level vs. team-level RFCs](../../README.md#project-level-vs-team-level-rfcs). 4 | 5 | ## Accepted RFCs 6 | 7 | * [0006: Add Process Reload Library to Paketo](0006-add-live-reload-library.md) 8 | * [0007: Health Checker Support](0007-health-checker-buildpack.md) 9 | 10 | ## Implemented RFCs 11 | 12 | * [0001: UPX Support](0001-upx-buildpack.md) 13 | * [0002: Syft Support](0002-syft-buildpack.md) 14 | * [0003: Credential Configuration in the Git Buildpack](0003-git-credential-configuration.md) 15 | * [0004: Git Buildpack Promotion](0004-git-promotion.md) 16 | * [0005: Source Removal Buildpack](0005-source-removal-buildpack.md) 17 | 18 | ## Links 19 | 20 | * The [Configuring Paketo Buildpacks Docs](https://paketo.io/docs/buildpacks/configuration/) describe many Paketo features that are implemented by utiltiy buildpacks. 21 | -------------------------------------------------------------------------------- /text/go/0000-template.md: -------------------------------------------------------------------------------- 1 | # {{TITLE: a human-readable title for this RFC!}} 2 | 3 | ## Proposal 4 | 5 | {{What changes are you proposing to the buildpack?}} 6 | 7 | ## Motivation 8 | 9 | {{Why are we doing this? What pain points does this resolve? What use cases does it support? What is the expected outcome? Use real, concrete examples to make your case!}} 10 | 11 | ## Implementation (Optional) 12 | 13 | {{Give a high-level overview of implementation requirements and concerns. Be specific about areas of code that need to change, and what their potential effects are. Discuss which repositories and sub-components will be affected, and what its overall code effect might be.}} 14 | 15 | ## Source Material (Optional) 16 | 17 | {{Any source material used in the creation of the RFC should be put here.}} 18 | 19 | ## Unresolved Questions and Bikeshedding (Optional) 20 | 21 | {{Write about any arbitrary decisions that need to be made (syntax, colors, formatting, minor UX decisions), and any questions for the proposal that have not been answered.}} 22 | 23 | {{REMOVE THIS SECTION BEFORE RATIFICATION!}} 24 | -------------------------------------------------------------------------------- /text/tooling/0000-template.md: -------------------------------------------------------------------------------- 1 | # {{TITLE: a human-readable title for this RFC!}} 2 | 3 | ## Proposal 4 | 5 | {{What changes are you proposing to the buildpack?}} 6 | 7 | ## Motivation 8 | 9 | {{Why are we doing this? What pain points does this resolve? What use cases does it support? What is the expected outcome? Use real, concrete examples to make your case!}} 10 | 11 | ## Implementation (Optional) 12 | 13 | {{Give a high-level overview of implementation requirements and concerns. Be specific about areas of code that need to change, and what their potential effects are. Discuss which repositories and sub-components will be affected, and what its overall code effect might be.}} 14 | 15 | ## Source Material (Optional) 16 | 17 | {{Any source material used in the creation of the RFC should be put here.}} 18 | 19 | ## Unresolved Questions and Bikeshedding (Optional) 20 | 21 | {{Write about any arbitrary decisions that need to be made (syntax, colors, formatting, minor UX decisions), and any questions for the proposal that have not been answered.}} 22 | 23 | {{REMOVE THIS SECTION BEFORE RATIFICATION!}} 24 | -------------------------------------------------------------------------------- /text/ruby/rake/0000-template.md: -------------------------------------------------------------------------------- 1 | # {{TITLE: a human-readable title for this RFC!}} 2 | 3 | ## Proposal 4 | 5 | {{What changes are you proposing to the buildpack?}} 6 | 7 | ## Motivation 8 | 9 | {{Why are we doing this? What pain points does this resolve? What use cases does it support? What is the expected outcome? Use real, concrete examples to make your case!}} 10 | 11 | ## Implementation (Optional) 12 | 13 | {{Give a high-level overview of implementation requirements and concerns. Be specific about areas of code that need to change, and what their potential effects are. Discuss which repositories and sub-components will be affected, and what its overall code effect might be.}} 14 | 15 | ## Source Material (Optional) 16 | 17 | {{Any source material used in the creation of the RFC should be put here.}} 18 | 19 | ## Unresolved Questions and Bikeshedding (Optional) 20 | 21 | {{Write about any arbitrary decisions that need to be made (syntax, colors, formatting, minor UX decisions), and any questions for the proposal that have not been answered.}} 22 | 23 | {{REMOVE THIS SECTION BEFORE RATIFICATION!}} 24 | -------------------------------------------------------------------------------- /text/ruby/passenger/0000-template.md: -------------------------------------------------------------------------------- 1 | # {{TITLE: a human-readable title for this RFC!}} 2 | 3 | ## Proposal 4 | 5 | {{What changes are you proposing to the buildpack?}} 6 | 7 | ## Motivation 8 | 9 | {{Why are we doing this? What pain points does this resolve? What use cases does it support? What is the expected outcome? Use real, concrete examples to make your case!}} 10 | 11 | ## Implementation (Optional) 12 | 13 | {{Give a high-level overview of implementation requirements and concerns. Be specific about areas of code that need to change, and what their potential effects are. Discuss which repositories and sub-components will be affected, and what its overall code effect might be.}} 14 | 15 | ## Source Material (Optional) 16 | 17 | {{Any source material used in the creation of the RFC should be put here.}} 18 | 19 | ## Unresolved Questions and Bikeshedding (Optional) 20 | 21 | {{Write about any arbitrary decisions that need to be made (syntax, colors, formatting, minor UX decisions), and any questions for the proposal that have not been answered.}} 22 | 23 | {{REMOVE THIS SECTION BEFORE RATIFICATION!}} 24 | -------------------------------------------------------------------------------- /text/builders/0000-template.md: -------------------------------------------------------------------------------- 1 | # {{TITLE: a human-readable title for this RFC!}} 2 | 3 | ## Proposal 4 | 5 | {{What changes are you purposing to the overall language family?}} 6 | 7 | ## Motivation 8 | 9 | {{Why are we doing this? What pain points does this resolve? What use cases does it support? What is the expected outcome? Use real, concrete examples to make your case!}} 10 | 11 | ## Implementation (Optional) 12 | 13 | {{Give a high-level overview of implementation requirements and concerns. Be specific about areas of code that need to change, and what their potential effects are. Discuss which repositories and sub-components will be affected, and what its overall code effect might be.}} 14 | 15 | ## Source Material (Optional) 16 | 17 | {{Any source material used in the creation of the RFC should be put here.}} 18 | 19 | ## Unresolved Questions and Bikeshedding (Optional) 20 | 21 | {{Write about any arbitrary decisions that need to be made (syntax, colors, formatting, minor UX decisions), and any questions for the proposal that have not been answered.}} 22 | 23 | {{REMOVE THIS SECTION BEFORE RATIFICATION!}} 24 | -------------------------------------------------------------------------------- /text/dotnet-core/assets/0001-original.dot: -------------------------------------------------------------------------------- 1 | digraph "original" { 2 | o_ne [label="node-engine"]; 3 | o_i [label="icu"]; 4 | o_dcr [label="dotnet-core-runtime"]; 5 | o_dca [label="dotnet-core-aspnet"]; 6 | o_dcs [label="dotnet-core-sdk"]; 7 | o_dcb [label="dotnet-core-build"]; 8 | o_dcc [label="dotnet-core-conf"]; 9 | 10 | o_dcr -> o_dcr [color=red]; 11 | 12 | o_dca -> o_dca [color=red]; 13 | o_dca -> o_dcr [color=red]; 14 | o_dca -> o_dcr [color=blue]; 15 | 16 | o_dcs -> o_dcs [color=red]; 17 | o_dcs -> o_dcs [color=blue]; 18 | o_dcs -> o_dcr [color=red]; 19 | o_dcs -> o_dcr [color=blue]; 20 | o_dcs -> o_dca [color=red]; 21 | o_dcs -> o_dca [color=blue]; 22 | 23 | o_dcb -> o_dcb [color=blue]; 24 | o_dcb -> o_dcs [color=blue]; 25 | o_dcb -> o_dcs [color=red]; 26 | o_dcb -> o_dcr [color=blue]; 27 | o_dcb -> o_dcr [color=red]; 28 | o_dcb -> o_ne [color=blue]; 29 | o_dcb -> o_ne [color=red]; 30 | o_dcb -> o_dca [color=blue]; 31 | o_dcb -> o_dca [color=red]; 32 | o_dcb -> o_i [color=blue]; 33 | 34 | o_dcc -> o_dcc [color=blue]; 35 | o_dcc -> o_i [color=red]; 36 | } 37 | -------------------------------------------------------------------------------- /text/ruby/0000-template.md: -------------------------------------------------------------------------------- 1 | # {{TITLE: a human-readable title for this RFC!}} 2 | 3 | ## Proposal 4 | 5 | {{What changes are you purposing to the overall language family?}} 6 | 7 | ## Motivation 8 | 9 | {{Why are we doing this? What pain points does this resolve? What use cases does it support? What is the expected outcome? Use real, concrete examples to make your case!}} 10 | 11 | ## Implementation (Optional) 12 | 13 | {{Give a high-level overview of implementation requirements and concerns. Be specific about areas of code that need to change, and what their potential effects are. Discuss which repositories and sub-components will be affected, and what its overall code effect might be.}} 14 | 15 | ## Source Material (Optional) 16 | 17 | {{Any source material used in the creation of the RFC should be put here.}} 18 | 19 | ## Unresolved Questions and Bikeshedding (Optional) 20 | 21 | {{Write about any arbitrary decisions that need to be made (syntax, colors, formatting, minor UX decisions), and any questions for the proposal that have not been answered.}} 22 | 23 | {{REMOVE THIS SECTION BEFORE RATIFICATION!}} 24 | -------------------------------------------------------------------------------- /text/ruby/bundle-install/0000-template.md: -------------------------------------------------------------------------------- 1 | # {{TITLE: a human-readable title for this RFC!}} 2 | 3 | ## Proposal 4 | 5 | {{What changes are you proposing to the buildpack?}} 6 | 7 | ## Motivation 8 | 9 | {{Why are we doing this? What pain points does this resolve? What use cases does it support? What is the expected outcome? Use real, concrete examples to make your case!}} 10 | 11 | ## Implementation (Optional) 12 | 13 | {{Give a high-level overview of implementation requirements and concerns. Be specific about areas of code that need to change, and what their potential effects are. Discuss which repositories and sub-components will be affected, and what its overall code effect might be.}} 14 | 15 | ## Source Material (Optional) 16 | 17 | {{Any source material used in the creation of the RFC should be put here.}} 18 | 19 | ## Unresolved Questions and Bikeshedding (Optional) 20 | 21 | {{Write about any arbitrary decisions that need to be made (syntax, colors, formatting, minor UX decisions), and any questions for the proposal that have not been answered.}} 22 | 23 | {{REMOVE THIS SECTION BEFORE RATIFICATION!}} 24 | -------------------------------------------------------------------------------- /text/dotnet-core/0000-template.md: -------------------------------------------------------------------------------- 1 | # {{TITLE: a human-readable title for this RFC!}} 2 | 3 | ## Proposal 4 | 5 | {{What changes are you purposing to the overall language family?}} 6 | 7 | ## Motivation 8 | 9 | {{Why are we doing this? What pain points does this resolve? What use cases does it support? What is the expected outcome? Use real, concrete examples to make your case!}} 10 | 11 | ## Implementation (Optional) 12 | 13 | {{Give a high-level overview of implementation requirements and concerns. Be specific about areas of code that need to change, and what their potential effects are. Discuss which repositories and sub-components will be affected, and what its overall code effect might be.}} 14 | 15 | ## Source Material (Optional) 16 | 17 | {{Any source material used in the creation of the RFC should be put here.}} 18 | 19 | ## Unresolved Questions and Bikeshedding (Optional) 20 | 21 | {{Write about any arbitrary decisions that need to be made (syntax, colors, formatting, minor UX decisions), and any questions for the proposal that have not been answered.}} 22 | 23 | {{REMOVE THIS SECTION BEFORE RATIFICATION!}} 24 | -------------------------------------------------------------------------------- /text/dependencies/rfcs/0000-template.md: -------------------------------------------------------------------------------- 1 | # {{TITLE: a human-readable title for this RFC!}} 2 | 3 | ## Proposal 4 | 5 | {{What changes are you purposing to the overall language family?}} 6 | 7 | ## Motivation 8 | 9 | {{Why are we doing this? What pain points does this resolve? What use cases does it support? What is the expected outcome? Use real, concrete examples to make your case!}} 10 | 11 | ## Implementation (Optional) 12 | 13 | {{Give a high-level overview of implementation requirements and concerns. Be specific about areas of code that need to change, and what their potential effects are. Discuss which repositories and sub-components will be affected, and what its overall code effect might be.}} 14 | 15 | ## Source Material (Optional) 16 | 17 | {{Any source material used in the creation of the RFC should be put here.}} 18 | 19 | ## Unresolved Questions and Bikeshedding (Optional) 20 | 21 | {{Write about any arbitrary decisions that need to be made (syntax, colors, formatting, minor UX decisions), and any questions for the proposal that have not been answered.}} 22 | 23 | {{REMOVE THIS SECTION BEFORE RATIFICATION!}} 24 | -------------------------------------------------------------------------------- /text/stacks/README.md: -------------------------------------------------------------------------------- 1 | # Stacks RFCs 2 | 3 | This directory contains RFCs that pertain to the [Stacks Subteam](https://github.com/paketo-buildpacks/community/blob/main/TEAMS.md#stacks-team). Please see the repo README for guidance on [project-level vs. team-level RFCs](../../README.md#project-level-vs-team-level-rfcs). 4 | 5 | ## Accepted RFCs 6 | 7 | * [0004: Stacks based on Ubuntu 2022.04: Jammy Jellyfish](0004-jammy-jellyfish.md) 8 | * [0006: Add to Tiny Run Image to Enable Node Apps](0006-node-on-tiny.md) 9 | * [0007: Squash Stack Images](0007-squash-stack.md) 10 | * [0008: Remove Ruby from the Jammy Full Stack](0008-jammy-full-remove-ruby.md) 11 | * [0009: Remove `yj` from all stacks](0009-remove-yj.md) 12 | 13 | ## Implemented RFCs 14 | 15 | * [0001: Add io.paketo.stack.packages label](0001-stack-package-metadata.md) 16 | * [0002: Add libz to the Tiny Run Image](0002-add-libz.md) 17 | * [0003: Stack Descriptor and Tooling](0003-stack-descriptor.md) 18 | * [0005: Updates to Stacks based on Ubuntu Bionic](0005-bionic-stack-updates.md) 19 | 20 | ## Links 21 | 22 | * [Stack Docs](https://paketo.io/docs/concepts/stacks/) 23 | -------------------------------------------------------------------------------- /text/go/0002-dependencies.md: -------------------------------------------------------------------------------- 1 | # Decide Which Go Dependencies Will Be Paketo-hosted 2 | 3 | ## Proposal 4 | 5 | The following dependencies should be removed as Paketo-hosted dependencies: 6 | * [Go Distribution](https://github.com/paketo-buildpacks/go-dist/blob/main/buildpack.toml) 7 | 8 | 9 | ## Rationale 10 | 11 | ### Go Distribution 12 | 13 | Remove the Paketo-hosted dependency. 14 | 15 | The buildpack can use the dependency that is provided by Go which can be parsed 16 | from a JSON payload of thier [download 17 | page](https://go.dev/dl/https://go.dev/dl/?mode=json&include=all) with little 18 | to no modification. The precedence for this payload page existing can be found 19 | in the [Go Docs for the 20 | website](https://pkg.go.dev/golang.org/x/website/internal/dl). The payload 21 | includes a SHA256 from Go meaning the artifact can be verified from the 22 | upstream. Here is a [proof of concept 23 | PR](https://github.com/paketo-buildpacks/go-dist/pull/442) showing the 24 | buildpack using the dependencies directly from the Go upstream. Because this 25 | dependency can be consumed from a trusted source, we should stop hosting it 26 | ourselves. 27 | -------------------------------------------------------------------------------- /text/0004-clojure.md: -------------------------------------------------------------------------------- 1 | # Leiningen (Clojure) Buildpack 2 | 3 | ## Summary 4 | 5 | A [Leiningen][l] buildpack for building Clojure applications has been created [by the community][b]. It is based on the same technologies and is nearly indistinguishable from the other Paketo Buildpacks, especially the JVM build-system buildpacks, and it should be adopted into the project. 6 | 7 | [l]: https://leiningen.org 8 | [b] https://github.com/eddumelendez/lein-paketo-buildpack/ 9 | 10 | ## Motivation 11 | 12 | This is an additional buildpack, for building JVM-based applications based on Clojure, and offers yet another workload that can be built by Paketo buildpacks. 13 | 14 | ## Detailed Explanation 15 | 16 | N/A 17 | 18 | ## Rationale and Alternatives 19 | 20 | N/A 21 | 22 | ## Implementation 23 | 24 | This buildpack will be adopted by the Java Buildpacks team and transferred to the `paketo` GitHub organization. The original author will retain full commit rights to the repository and be entitled to a full say in the direction and features of the buildpack. 25 | 26 | ## Prior Art 27 | 28 | N/A 29 | 30 | ## Unresolved Questions and Bikeshedding 31 | 32 | N/A 33 | -------------------------------------------------------------------------------- /text/php/0004-dependencies.md: -------------------------------------------------------------------------------- 1 | # Decide which PHP dependencies will be Paketo-hosted 2 | 3 | ## Proposal 4 | 5 | Currently two PHP buildpacks have Paketo-hosted dependencies. 6 | 7 | | Buildpack | Action | 8 | |------------------------------------------------------------------------------------|--------| 9 | | [php-dist](https://github.com/paketo-buildpacks/php-dist/blob/main/buildpack.toml) | Keep | 10 | | [composer](https://github.com/paketo-buildpacks/composer/blob/main/buildpack.toml) | Remove | 11 | 12 | ## Rationale 13 | 14 | ### PHP-Dist 15 | 16 | Keep this as a Paketo-hosted dependency. 17 | 18 | Currently this uses `dep-server`, `binary-builder`, and `buildpacks-ci` to build. 19 | Buildpack maintainers will move this process to the new dependency workflow. 20 | 21 | ### Composer 22 | 23 | The Composer dependency is currently (as of [2c39d25a](https://github.com/paketo-buildpacks/composer/commit/2c39d25a22f6403a9f77854c9b9247611e168049)) 24 | exactly the same as the upstream. 25 | Note that `sha256` and `source_sha256` have been identical for the lifetime of this buildpack. -------------------------------------------------------------------------------- /text/0021-go-generate-buildpack.md: -------------------------------------------------------------------------------- 1 | # Paketo Community Go Generate Buildpack. 2 | 3 | ## Proposal 4 | 5 | An optional buildpack for the Go language family that runs `go generate`. 6 | 7 | 8 | ## Motivation 9 | 10 | For some Go applications, generated files are not committed to the repository. 11 | They are expected to be generated at buildtime (for example, generating 12 | embedded files.) 13 | 14 | Technically, this buildpack would run before the `go-build` buildpack 15 | in a custom builder's configuration as we are not looking to integrate 16 | this buildpack into the Go language family buildpack 17 | [at this time](https://github.com/paketo-buildpacks/go/pull/367#issuecomment-771886349). 18 | There is [another RFC](https://github.com/paketo-buildpacks/go/pull/367) 19 | for adopting this buildpack into the Go language family buildpack if it makes sense. 20 | 21 | ## Implementation 22 | 23 | A new `go-generate` buildpack will be developed to run the command `go generate ./...` 24 | when `BP_GO_GENERATE=true`. 25 | Eventually, it can be optimized to allow specifying _which_ generate commands 26 | should be run as defined in the other RFC. 27 | 28 | ### Detection Crtieria 29 | 30 | The buildpack will pass detection if the `BP_GO_GENERATE` environment variable 31 | is set to `true`. 32 | 33 | ### Build Process 34 | 35 | The buildpack will run `go generate ./...` in the directory. 36 | -------------------------------------------------------------------------------- /text/nodejs/0007-npm-install-re-architecture.md: -------------------------------------------------------------------------------- 1 | # Refactoring the NPM Buildpack 2 | 3 | ## Proposal 4 | 5 | This RFC aims to outline the changes required to create an `npm-install` 6 | buildpack from the current `npm` buildpack, in alignment with the [Node.js 7 | re-architecture](https://github.com/paketo-buildpacks/nodejs/blob/main/rfcs/0001-buildpacks-architecture.md) 8 | RFC. 9 | 10 | ## Motivation 11 | 12 | As part of the Node.js re-architecture, the group of buildpacks used to build 13 | an app which uses npm has changed. The `node-engine` buildpack provides `node` 14 | and `npm`, and the `npm-start` buildpack bookends the order grouping by setting 15 | the relevant start command with `tini`. Thus, there is a need for a buildpack 16 | which generates and provides a given application's `node_modules`. 17 | 18 | ## Integration 19 | 20 | This buildpack will provide `node_modules` and will require `node` and `npm` at 21 | build time. 22 | 23 | 24 | ## Implementation 25 | 26 | The major changes to the existing `npm` buildpack will be as follows: 27 | 28 | 1. Change the name of the buildpack to `npm-install`. 29 | 2. The buildpack will no longer set a start command, that is now the job of 30 | `npm-start`. 31 | 3. The buildpack will no longer require itself, `npm-start` now requires 32 | `node_modules` to trigger detection for this buildpack. 33 | 4. The buildpack will now require `node` and `npm` at build. 34 | -------------------------------------------------------------------------------- /text/utilities/0004-git-promotion.md: -------------------------------------------------------------------------------- 1 | # Git Buildpack Promotion 2 | 3 | ## Summary 4 | 5 | A [Git Buildpack](https://github.com/paketo-community/git) exists as a 6 | community created buildpack in the [Paketo Community 7 | Org](https://github.com/paketo-community/git). This RFC proposes the promotion 8 | of the Git Buildpack from a "Community" buildpack to an official Paketo 9 | Buildpack. 10 | 11 | ## Motivation 12 | 13 | The community Git Buildpack has reached an initial feature completion state and 14 | supports the ability to configure git authentication credentials. The ability 15 | to configure credentials allows language tools that install modules using `git` 16 | (such as `npm` or `go get`) to install private modules that are in repos that 17 | require credentials to access. 18 | 19 | ## Implementation 20 | 21 | The following changes will be made: 22 | 23 | - [Git Buildpack](https://github.com/paketo-community/git) moved from the 24 | `paketo-community` to `paketo-buildpacks`and become a part of the Utility 25 | sub-team. 26 | - Buildpack will have `paketo-buildpacks/git` ID. 27 | - Buildpack will be published to `paketobuildpacks/git`. 28 | - Versioning of the buildpack will continue as is. 29 | - Sample apps for common Git buildpacks configurations should be added to the 30 | [Paketo samples repo](https://github.com/paketo-buildpacks/samples) 31 | - Git buildpack docs should be added to the repos README. 32 | -------------------------------------------------------------------------------- /text/0047-promote-web-servers-buildpack.md: -------------------------------------------------------------------------------- 1 | 2 | # Web Servers Buildpack Promotion 3 | 4 | ## Summary 5 | 6 | A [Web Servers Buildpack](https://github.com/paketo-community/web-servers) exists as a 7 | community created buildpack in the [Paketo Community 8 | Org](https://github.com/paketo-community/web-servers). This RFC proposes the promotion 9 | of the Web Servers Buildpack from a "Community" buildpack to an official Paketo 10 | Buildpack. 11 | 12 | ## Motivation 13 | 14 | The community Web Servers Buildpack has reached an initial feature completion 15 | state and supports a wide range of static applications through HTTPD and NGINX 16 | as well as applications with Javascript frontends. 17 | 18 | ## Implementation 19 | 20 | The following changes will be made: 21 | 22 | - [Web Servers Buildpack](https://github.com/paketo-community/web-servers) moved from the 23 | `paketo-community` to `paketo-buildpacks`and become a part of the Utility 24 | sub-team. 25 | - Buildpack will have `paketo-buildpacks/web-servers` ID. 26 | - Buildpack will be published to `paketobuildpacks/web-servers`. 27 | - Buildpack will be Paketo Full Builder and the stand-alone entries for NGINX and HTTPD will be removed. 28 | - Versioning of the buildpack will continue as is. 29 | - Sample apps for common Web Servers buildpacks configurations should be added to the 30 | [Paketo samples repo](https://github.com/paketo-buildpacks/samples) 31 | - Web Sever buildpack documentation should be added to the repos README. 32 | -------------------------------------------------------------------------------- /text/go/0001-remove-dep.md: -------------------------------------------------------------------------------- 1 | # Remove the `dep` and `dep-ensure` Buildpacks 2 | 3 | ## Proposal 4 | 5 | The `dep` and `dep-ensure` Buildpacks should be removed. 6 | 7 | ## Motivation 8 | 9 | `dep` was a package management tool created for Go before the introduction of 10 | `go mod`. Since the introduction of `go mod` the `dep` tool has since been 11 | deprecated and archived by the team working on it (See the [Github 12 | Repository](https://github.com/golang/dep) and the [`dep` 13 | documentation](https://golang.github.io/dep/docs/introduction.html)). Because 14 | this tool has been deprecated and `go mod` has been widely adopted by the Go 15 | community, we should remove our buildpacks. 16 | 17 | ## Implementation 18 | 19 | Put in place a 30 day deprecation window in which we print to the logs that the 20 | `dep` and `dep-ensure` buildpacks will soon be archived and removed from the 21 | language family. 22 | 23 | After this 30 day deprecation window the following should be done to remove the 24 | `dep` tool: 25 | - Archive both the `dep` and `dep-ensure` buildpack repositories 26 | - Remove any and all related order groups from the language family buildpack 27 | - Remove logic in `go-build` designed to accomodate for a use of the `dep` tool 28 | - Remove any samples in the samples repository that use the `dep` tool 29 | - Change the documentation on the website by either removing `dep` specific 30 | documentation or replace it with an indication that the workflow has been 31 | removed 32 | -------------------------------------------------------------------------------- /text/stacks/0009-remove-yj.md: -------------------------------------------------------------------------------- 1 | # Remove the `yj` binary from stacks 2 | 3 | ## Proposal 4 | 5 | At the moment, all of the stacks are shipping the `yj` binary into the generated build images. Given that Paketo buildpacks are all written in Go and can read/write TOML using libraries, there doesn't seem like a need for `yj` in our stacks. 6 | 7 | I'm proposing that we should remove it. 8 | 9 | ## Motivation 10 | 11 | There are two motivations: 12 | 13 | 1. It's extra stuff in the build image, so it requires being kept up-to-date and it takes up space (not much, about 4.5M). It also reduces the number of layers by one. 14 | 15 | 2. Because it is distributed through a Github release, not a package manager, it is more difficult to get this binary installed into the stack with the addition of multi-arch stacks. It involves picking the right architecture and downloading the right binary for that architecture. It's not insurmountable, but it is extra work and complexity for something that appears to be extraneous to the stack. 16 | 17 | ## Implementation 18 | 19 | In the build `Dockerfile` for each stack, there is a line like this: 20 | 21 | ``` 22 | RUN curl -sSfL -o /usr/local/bin/yj https://github.com/sclevine/yj/releases/latest/download/yj-linux-amd64 \ 23 | && chmod +x /usr/local/bin/yj 24 | ``` 25 | 26 | This line should be removed. 27 | 28 | ## Unresolved Questions and Bikeshedding 29 | 30 | 1. Is someone actually using and depending on `yj` to be present? If so, please include your use case. 31 | -------------------------------------------------------------------------------- /text/nodejs/0009-npm-start-command.md: -------------------------------------------------------------------------------- 1 | # Writing an `npm start` command 2 | 3 | ## Proposal 4 | 5 | As part of the re-architecture of the Node.js metabuildpack outlined 6 | [here](https://github.com/paketo-buildpacks/nodejs/blob/main/rfcs/0001-buildpacks-architecture.md), 7 | there is need for a `npm-start` buildpack with the single responsibility of 8 | setting a start command which uses `tini` and `npm`. 9 | 10 | 11 | ## Motivation 12 | 13 | Moving toward this single-responsibility architecture has a few advantages: 14 | 15 | * It enables greater modularity within the Node.js language family. 16 | 17 | * It sets the foundation for interoperability between buildpacks across 18 | language families. 19 | 20 | * Using `tini` allows for more optimal process management within the container. 21 | 22 | `tini` is a process manager for containers which manages zombie processes and 23 | performs signal forwarding. Using an app start command with `tini` ensures 24 | that containers may be stopped gracefully once started. 25 | 26 | ## Integration 27 | 28 | The buildpack will provide no dependencies and will require `node`, `tini`, 29 | `npm` and `node_modules` during the launch phase. 30 | 31 | ## Implementation (Optional) 32 | 33 | Detection will pass once a `package.json` file is present in the app's source 34 | code, assuming all other buildplan requirements have been met. 35 | 36 | If detection is passed, the buildpack will set a start command using `tini` and 37 | `npm`. An example of a start command could be: `tini -g -- npm start`. 38 | -------------------------------------------------------------------------------- /text/nodejs/0010-yarn-start-command.md: -------------------------------------------------------------------------------- 1 | # Writing a Yarn Start Command 2 | 3 | ## Proposal 4 | 5 | As part of the re-architecture of the Node.js metabuildpack outlined 6 | [here](https://github.com/paketo-buildpacks/nodejs/blob/main/rfcs/0001-buildpacks-architecture.md), 7 | there is need for a `yarn-start` buildpack with the single responsibility of 8 | setting a start command which uses `tini` and `yarn`. 9 | 10 | 11 | ## Motivation 12 | 13 | Moving toward this single-responsibility architecture has a few advantages: 14 | 15 | * It enables greater modularity within the Node.js language family. 16 | 17 | * It sets the foundation for interoperability between buildpacks across 18 | language families. 19 | 20 | * Using `tini` allows for more optimal process management within the container. 21 | 22 | `tini` is a process manager for containers which manages zombie processes and 23 | performs signal forwarding. Using an app start command with `tini` ensures 24 | that containers may be stopped gracefully once started. 25 | 26 | ## Integration 27 | 28 | The buildpack will provide no dependencies and will require `node`, `tini`, 29 | `yarn` and `node_modules` during the launch phase. 30 | 31 | ## Implementation (Optional) 32 | 33 | Detection will pass once a `yarn.lock` file is present in the app's source 34 | code, assuming all other buildplan requirements have been met. 35 | 36 | If detection is passed, the buildpack will set a start command using `tini` and 37 | `yarn`. An example of a start command could be: `tini -g -- yarn start`. 38 | -------------------------------------------------------------------------------- /text/java/0014-selecting-default-java-version.md: -------------------------------------------------------------------------------- 1 | # Selecting the next default Java Version for Paketo Buildpacks 2 | 3 | ## Summary 4 | 5 | This RFC introduces a process to select the next default version of the Paketo Java Buildpack. 6 | 7 | ## Motivation 8 | 9 | Currently, there is no process how the default version of Java is picked in the Paketo world. As of today (January 2023), the default still is Java 11 (released September 2018) although Java 17 (released September 2021) is already available. 10 | 11 | ## Detailed Explanation 12 | 13 | The default should be changed according to a defined process rather than at some undefined point in time to some undefined version. To do so, the default should be changed once the latest released LTS version of Java is at least one year old. Exceptions are permitted for a shorter change cycle when deemed sufficiently urgent by a majority vote of Java subteam contributors and maintainers. 14 | 15 | ## Rationale and Alternatives 16 | 17 | - Do nothing, update default manually from time to time 18 | - Always use the latest LTS immediately 19 | - Could break people immediately 20 | - This RFC 21 | - Gives room to adapt to breaking changes 22 | 23 | ## Implementation 24 | 25 | To fulfill this RFC, the default version should be changed to Java 17 immediately. Additionally, the process on how the community is notified about the update should be documented on paketo.io/docs. 26 | 27 | Going forward, the default Java version should be bumped according to this RFC. 28 | 29 | ## Unresolved Questions and Bikeshedding 30 | 31 | - Define the time to wait after a new LTS was published 32 | - Should this be an automated process? 33 | -------------------------------------------------------------------------------- /text/nodejs/0017-promote-ubi-nodejs-extension.md: -------------------------------------------------------------------------------- 1 | # Promote the ubi-nodejs-extension to paketo-buildpacks 2 | 3 | ## Summary 4 | 5 | Promote the the [ubi-nodejs-extension](https://github.com/paketo-community/ubi-nodejs-extension) 6 | from paketo-community to paketo-buildpacks. 7 | 8 | ## Motivation 9 | 10 | The ubi-nodejs-extension has been building and releases have been published regularly over the 11 | last year. There are no outstanding major issues and we've not had to make any substantial 12 | changes over the last few months and it seems like it's time to be promoted. 13 | 14 | In addition, the extension mechanism is no longer experimental. 15 | 16 | ## Detalied Explanation 17 | 18 | ## Rational and Alternatives 19 | 20 | UBI support was planned and agreed in this rfc - 21 | [https://github.com/paketo-buildpacks/rfcs/blob/main/text/0056-ubi-based-stacks.md?](https://github.com/paketo-buildpacks/rfcs/blob/main/text/0056-ubi-based-stacks.md) 22 | 23 | Promotion of the ubi-nodejs-extension is a step towards completing this and the ubi-nodejs-extension 24 | is ready and actively maintained with no major open issues and regular releases. 25 | 26 | The alternative is to leave the ubi-nodejs-extension in paketo-community to bake for a while longer 27 | 28 | ## Implementation 29 | 30 | * Move the paketo-community/ubi-nodejs-extension repo to `paketo-buildpacks/ubi-nodejs-extension` 31 | * Fixup and changes needed in the automation scripts, etc. 32 | * Update references in the paketo-buildpackes/nodejs meta buildpack to point to 33 | `paketo-buildpacks/ubi-nodejs-extension`. 34 | 35 | ## Prior Art 36 | 37 | ## Unresolved Questions and Bikeshedding 38 | 39 | N/A 40 | 41 | 42 | -------------------------------------------------------------------------------- /text/stacks/0008-jammy-full-remove-ruby.md: -------------------------------------------------------------------------------- 1 | # Remove Ruby from the Jammy Full Stack 2 | 3 | ## Summary 4 | 5 | The Jammy Full stack should not install the `ruby` package. 6 | 7 | ## Motivation 8 | 9 | The `ruby` (Ruby 3.0) package will reach the end of its support period (March 10 | 2024) before Jammy does (April 2027). This means that for a large portion of 11 | the support period for the Jammy Full stack, it will contain an unsupported 12 | Ruby interpreter. 13 | 14 | Additionally, removing the `ruby` package will have little impact on existing 15 | Jammy Full stack users since they will be able to still get a Ruby interpreter 16 | through the `mri` buildpack or by employing a stack extension to install the 17 | `ruby` package. 18 | 19 | Finally, the existence of the `ruby` package in the stack is a relic of its 20 | ancestry having been developed from the Cloud Foundry `cflinuxfs*` line of stack 21 | images. In those stacks, the `ruby` package was required because some number of 22 | buildpacks were written in Ruby and required an interpreter on the stack to 23 | run. Given that Paketo does not have any buildpacks written in Ruby, the 24 | original rationale for including the `ruby` package is gone. 25 | 26 | ## Detailed Explanation 27 | 28 | Removing the `ruby` package from both the build and run image definitions in 29 | the `stack.toml` file will result in an image that no longer includes that 30 | package. 31 | 32 | ## Rationale and Alternatives 33 | 34 | ## Implementation 35 | 36 | Remove the `ruby` package from the build and run package lists in the 37 | `stack.toml` file. 38 | 39 | ## Prior Art 40 | 41 | None 42 | 43 | ## Unresolved Questions and Bikeshedding 44 | 45 | None 46 | -------------------------------------------------------------------------------- /text/0024-utility-buildpacks-team.md: -------------------------------------------------------------------------------- 1 | # Utility Buildpacks Team 2 | 3 | ## Summary 4 | 5 | A team should be made that would be in charge in maintaining all of the so 6 | called "utility" buildpacks, which is to say buildpacks that have cross 7 | cutting, language agnostic usage. 8 | 9 | ## Motivation 10 | 11 | Currently, there is no body that exists for buildpacks that do have large cross 12 | cutting usage, which has led to these buildpacks being in many disparate 13 | groups. There are several reasons why consolidating these buildpacks into one 14 | group makes sense. 15 | * Having the buildpacks in a seperate group will make it more evident that they 16 | are langugae agnostic. 17 | * Having a separate maintainer group will hopefully encourage input from a 18 | wider range of user to make contributions. 19 | * Having a separate maintainer group will make it more evident where new cross 20 | cutting buildpacks (take the git buildpack as an example) should be added. 21 | 22 | 23 | ## Rationale and Alternatives 24 | 25 | * We do not create a new maintainer group and just leave the buildpacks in 26 | their existing teams. 27 | 28 | ## Implementation 29 | 30 | A new team called `Utility` should be formed and the following buildpacks 31 | should fall under that teams umbrella: 32 | * Procfile 33 | * CA Certificates 34 | * Environment Variables 35 | * Image Labels 36 | * Build Plan 37 | * Git 38 | * Tini 39 | 40 | The current maintainers and contributors of those buildpacks should become 41 | maintainers and contributors on the new `Utility` team in order to maintain 42 | continuity and avoid having to cast for a whole new set of maintainers. 43 | 44 | {{REMOVE THIS SECTION BEFORE RATIFICATION!}} 45 | -------------------------------------------------------------------------------- /text/0026-environment-variable-configuration-of-buildpacks.md: -------------------------------------------------------------------------------- 1 | # Environment Variable Configuration Of Buildpack 2 | Supersedes [RFC #0003](https://github.com/paketo-buildpacks/rfcs/blob/main/text/0003-replace-buildpack-yml.md) 3 | 4 | ## Summary 5 | 6 | Environment variables passed in at build time via the command line or 7 | `project.toml` should be the main means for user configuration of a buildpack's 8 | detect/build processes. 9 | 10 | ## Motivation 11 | 12 | There are often situations in which users need to configure or customize 13 | aspects about their applications build process (i.e. build flags in Go, project 14 | path in .Net, etc). There are also some buildpacks specific settings 15 | (dependency versions) that the user might also want/need to control. 16 | 17 | ## Detailed Explanation 18 | 19 | In [RFC #0003](https://github.com/paketo-buildpacks/rfcs/blob/main/text/0003-replace-buildpack-yml.md) 20 | it was proposed to use the Build Plan buildpack to pass all configuration as 21 | part of the `build plan`. This proved to have unforeseen negative consequences, 22 | chief among them there was no way to pass configuration data to the detect 23 | process of a buildpack because the information embedded in the `build plan` 24 | would only become available to the buildpack in the `buildpack plan` during 25 | build. It has since been decided in a number of the buildpack families to use 26 | environment variables instead of the Build Plan buildpack. 27 | 28 | This RFC is meant to catalog this distributed design decision. This RFC is also 29 | meant to be a formal superseding [RFC #0003](https://github.com/paketo-buildpacks/rfcs/blob/main/text/0003-replace-buildpack-yml.md) 30 | to ensure the chain of decision making remains somewhat intact. 31 | -------------------------------------------------------------------------------- /text/0000-template.md: -------------------------------------------------------------------------------- 1 | # {{TITLE: a human-readable title for this RFC!}} 2 | 3 | ## Summary 4 | 5 | {{A concise, one-paragraph description of the change.}} 6 | 7 | ## Motivation 8 | 9 | {{Why are we doing this? What pain points does this resolve? What use cases does it support? What is the expected outcome? Use real, concrete examples to make your case!}} 10 | 11 | ## Detailed Explanation 12 | 13 | {{Describe the expected changes in detail.}} 14 | 15 | ## Rationale and Alternatives 16 | 17 | {{Discuss 2-3 different alternative solutions that were considered. This is required, even if it seems like a stretch. Then explain why this is the best choice out of available ones.}} 18 | 19 | ## Implementation 20 | 21 | {{Give a high-level overview of implementation requirements and concerns. Be specific about areas of code that need to change, and what their potential effects are. Discuss which repositories and sub-components will be affected, and what its overall code effect might be.}} 22 | 23 | {{THIS SECTION IS REQUIRED FOR RATIFICATION -- you can skip it if you don't know the technical details when first submitting the proposal, but it must be there before it's accepted.}} 24 | 25 | ## Prior Art 26 | 27 | {{This section is optional if there are no actual prior examples in other tools.}} 28 | 29 | {{Discuss existing examples of this change in other tools, and how they've addressed various concerns discussed above, and what the effect of those decisions has been.}} 30 | 31 | ## Unresolved Questions and Bikeshedding 32 | 33 | {{Write about any arbitrary decisions that need to be made (syntax, colors, formatting, minor UX decisions), and any questions for the proposal that have not been answered.}} 34 | 35 | {{REMOVE THIS SECTION BEFORE RATIFICATION!}} 36 | -------------------------------------------------------------------------------- /text/builders/0001-buildpack-order.md: -------------------------------------------------------------------------------- 1 | # Proposed Buildpack Ordering in a Builder 2 | 3 | ## Summary 4 | 5 | `pack inspect-builder gcr.io/paketo-buildpack/builder` should display a valid `Detection Order`. 6 | 7 | ## Motivation 8 | 9 | After a change to the builder detection order it became impossible for `php` apps to detect, because `nginx` and `httpd` were before `php` in the detect order. 10 | The `httpd.conf` or `nginx.conf` included in `php` apps will cause the `nginx` or `http` buildpacks to detect `true` before `php` ever gets to run `detect`, 11 | making it impossible to access the `php` buildpack. 12 | 13 | 14 | ## Detailed Explanation 15 | 16 | We propose the following order based on the historical needs of app developers: 17 | 18 | - paketo-buildpacks/staticfile 19 | - paketo-community/ruby 20 | - paketo-buildpacks/dotnet-core 21 | - paketo-buildpacks/nodejs 22 | - paketo-buildpacks/go 23 | - paketo-community/python 24 | - paketo-buildpacks/php 25 | - paketo-buildpacks/nginx 26 | - paketo-buildpacks/httpd 27 | - paketo-buildpacks/java 28 | - paketo-buildpacks/procfile 29 | 30 | Any new buidpack will need careful consideration before deciding its place in the order. 31 | 32 | ## Rationale and Alternatives 33 | 34 | An alternative solution can be found [here](https://github.com/paketo-buildpacks/builder/pull/22), in which we propose an algorithm to order buildpacks. 35 | 36 | This was rejected because, based on experience in cloud foundry, we found that a certain ordering makes the most sense for the most developers. 37 | 38 | For example, dotnet-core apps often contain `package.json` files, so `dotnet-core` must come before `nodejs`. 39 | 40 | Also, `staticfile` must come first because it can not infer detection from the source code, but must rely on `buildpack.yml` property. 41 | -------------------------------------------------------------------------------- /text/nodejs/0002-remove-tini.md: -------------------------------------------------------------------------------- 1 | # Remove Tini Buildpack 2 | 3 | ## Summary 4 | 5 | The inclusion of `tini` in this buildpack is no longer required as the 6 | `npm-start` and `yarn-start` buildpacks have moved away from its use. We should 7 | remove references to the `tini` buildpack. 8 | 9 | ## Motivation 10 | 11 | The integration tests for `npm-start` and `yarn-start` have shown that using 12 | `tini` to manage processes in concert with `npm` and `yarn` is unreliable. 13 | Those buildpacks have been factored in a [Yarn Start 14 | RFC0002](https://github.com/paketo-buildpacks/yarn-start/blob/main/rfcs/0002-reimplement-start-command.md) 15 | and [NPM Start RFC 16 | 0002](https://github.com/paketo-buildpacks/npm-start/blob/main/rfcs/0002-reimplement-start-command.md) 17 | to remove `tini` from their launch process command. 18 | 19 | The language-family buildpack should be updated to reflect these changes. 20 | 21 | ## Proposal 22 | 23 | Remove the `tini` buildpack from the Yarn and NPM buildpack group orderings. 24 | When complete, the `buildpack.toml` should have the following structure: 25 | 26 | ```toml 27 | [[order]] 28 | 29 | [[order.group]] 30 | id = "paketo-buildpacks/node-engine" 31 | 32 | [[order.group]] 33 | id = "paketo-buildpacks/yarn" 34 | 35 | [[order.group]] 36 | id = "paketo-buildpacks/yarn-install" 37 | 38 | [[order.group]] 39 | id = "paketo-buildpacks/yarn-start" 40 | 41 | [[order]] 42 | 43 | [[order.group]] 44 | id = "paketo-buildpacks/node-engine" 45 | 46 | [[order.group]] 47 | id = "paketo-buildpacks/npm-install" 48 | 49 | [[order.group]] 50 | id = "paketo-buildpacks/npm-start" 51 | 52 | [[order]] 53 | 54 | [[order.group]] 55 | id = "paketo-buildpacks/node-engine" 56 | 57 | [[order.group]] 58 | id = "paketo-buildpacks/node-start" 59 | ``` 60 | -------------------------------------------------------------------------------- /text/0014-rust.md: -------------------------------------------------------------------------------- 1 | # Paketo Community Rust Buildpack 2 | 3 | ## Summary 4 | 5 | A [Rust Cloud Native Buildpack](https://github.com/dmikusa/rust-cnb) for building Rust applications has been created by [@dmikusa][@dmikusa]. It is built using common tooling used by the Paketo Buildpacks project and should be adopted into the Paketo Community Github Org. 6 | 7 | ## Motivation 8 | 9 | We would like to move the Rust CNB into the Paketo Community so that the community can use it to build Rust applications. This will also give the buildpack maintainer the ability to leverage common Paketo tooling to keep the buildpack dependencies updated and release the buildpack. 10 | 11 | ## Detailed Explanation 12 | 13 | N/A 14 | 15 | ## Rationale and Alternatives 16 | 17 | N/A 18 | 19 | ## Implementation 20 | 21 | The Rust Buildpacks will be moved into the `paketo-community` Github organization and a new Rust sub-team will be created. Initial maintainer for this team will be [@dmikusa][@dmikusa]. 22 | 23 | The following changes will be made: 24 | - [Rust CNB](https://github.com/dmikusa/rust-cnb) moved to Paketo Community 25 | - [Rust Dist CNB](https://github.com/dmikusa/rust-dist-cnb) moved to Paketo Community 26 | - [Rust Cargo CNB](https://github.com/dmikusa/rust-cargo-cnb) moved to Paketo Community 27 | - All buildpacks will have `paketo-community/` ID 28 | - Buildpack will be published to `gcr.io/paketo-community/rust` 29 | 30 | ## Prior Art 31 | 32 | [Leiningen Buildpack](https://github.com/paketo-buildpacks/rfcs/blob/master/accepted/0004-clojure.md) 33 | 34 | ## Unresolved Questions and Bikeshedding 35 | 36 | **Eventually** the Core Dependencies team should publish the Rust dependency so that the Rust team can consume it from the dependency server to provide dependency updates. 37 | 38 | [@dmikusa]: https://github.com/dmikusa 39 | -------------------------------------------------------------------------------- /text/java/0018-retire-java-azure-composite.md: -------------------------------------------------------------------------------- 1 | # Retire Java Azure Composite Buildpack 2 | 3 | ## Summary 4 | 5 | This RFC is to retire and archive the Java Azure Composite buildpack. 6 | 7 | ## Motivation 8 | 9 | 1. The buildpack is not being maintained. It hasn't been updated in a long time. 10 | 2. No one has complained that it's not been updated, which is a signal no one is using it. 11 | 3. The buildpack is not ultimately necessary as the main feature is that it uses a different JVM, which one can do without creating an entirely new buildpack. 12 | 4. We are introducing the jvm-vendors buildpack, which will even more easily allow users to pick different JVMs. 13 | 5. We don't want to set an expectation that we will create composite buildpacks for every JVM vendor. 14 | 15 | ## Detailed Explanation 16 | 17 | The process is simple. 18 | 19 | 1. Write a blog post announcing the change. Provide instructions for how to continue using Microsoft JDK without this buildpack. 20 | 2. Give users 30 days to update. 21 | 3. Archive the buildpack on Github. This will stop all workflows. 22 | 4. Delete the "latest" tag on the Docker Hub repository for `paketobuildpacks/java-azure`. 23 | 24 | ## Rationale and Alternatives 25 | 26 | 1. We don't want to have unmaintained buildpacks. This presents a bad look, but it can also result in users running old and insecure software. 27 | 2. Lack of effort/interest in maintaining this buildpack. 28 | 29 | The only alternative is for someone to step forward and consistently maintain and update this buildpack. Even then, this buildpack doesn't fit with the future direction of where we want to go with the Java buildpacks so that probably wouldn't be sufficient. 30 | 31 | ## Implementation 32 | 33 | See Detailed Explanation. 34 | 35 | ## Prior Art 36 | 37 | N/A 38 | 39 | ## Unresolved Questions and Bikeshedding 40 | 41 | None -------------------------------------------------------------------------------- /text/0023-git-buildpack.md: -------------------------------------------------------------------------------- 1 | # Git Support 2 | 3 | ## Proposal 4 | 5 | Introduce an (optional) Git buildpack into each language buildpack family. The buildpack 6 | will be charged with providing `git` metadata as build-time and run-time environment 7 | variables. 8 | 9 | This buildpack would be maintained by the existing Tooling team. 10 | ## Motivation 11 | 12 | Applications of any language may have a need for information extracted from 13 | `git` metadata. For example, the commit sha might be used as versioning 14 | information when building a Go binary or used when running a Rails application. 15 | 16 | ## Implementation 17 | 18 | A new `git` buildpack will be developed to detect whether the `.git` directory, and then 19 | read the directory to extract the following environment variables so that they 20 | can be included in the built image. 21 | 22 | - `REVISION` 23 | 24 | ### Detection Criteria 25 | 26 | The buildpack will detect if the `.git` directory is present. 27 | 28 | ### Build Process 29 | 30 | The build process of the buildpack will find the values for the 31 | expected environment variables and add them to a layer for use at launch. 32 | 33 | ### Buildpack Order Grouping 34 | 35 | The `git` buildpack can be added to each family buildpack or it can be added 36 | separately at the beginning of each ordering defined in a builder. 37 | 38 | For example: 39 | 40 | ```toml 41 | [[order]] 42 | 43 | [[order.group]] 44 | id = "paketo-buildpacks/git" 45 | version = "" 46 | optional = true 47 | 48 | [[order.group]] 49 | id = "paketo-buildpacks/go" 50 | version = "" 51 | 52 | [[order]] 53 | 54 | [[order.group]] 55 | id = "paketo-buildpacks/git" 56 | version = "" 57 | optional = true 58 | 59 | [[order.group]] 60 | id = "paketo-buildpacks/ruby" 61 | version = "" 62 | ``` 63 | -------------------------------------------------------------------------------- /text/java/README.md: -------------------------------------------------------------------------------- 1 | # Java RFCs 2 | 3 | This directory contains RFCs that pertain to the [Java Subteam](https://github.com/paketo-buildpacks/community/blob/main/TEAMS.md#java-team). Please see the repo README for guidance on [project-level vs. team-level RFCs](../../README.md#project-level-vs-team-level-rfcs). 4 | 5 | ## Accepted RFCs 6 | 7 | * [0007: Memory Calculator Low Profile Mode](0007-low-profile-memory-calc.md) 8 | * [0015: Create a draft branch for composite/meta buildpacks](0015-composite-draft-branch.md) 9 | * [0016: Add additional JVMs to the Java buildpack](0016-alternate-jvms-in-java-buildpack.md) 10 | * [0017: Add support for Oracle GraalVM and update GraalVM CE buildpack](0017-graalvm-jdk.md) 11 | 12 | ## Implemented RFCs 13 | 14 | * [0001: Microsoft OpenJDK Buildpack](0001-microsoft-jdk.md) 15 | * [0002: Alibaba Dragonwell Buildpack](0002-alibaba-jdk.md) 16 | * [0003: Retire Java Kill Agent](0003-retire-kill-agent.md) 17 | * [0004: Merge Java Feature Flag Buildpacks](0004-merge-java-feature-flag-buildpacks.md) 18 | * [0005: Clojure Tools](0005-clojure-tools.md) 19 | * [0006: Oracle JDK](0006-oracle.jdk) 20 | * [0008: Add Open Liberty buildpack to the Java buildpack](0008-add-liberty-to-java-composite.md) 21 | * [0009: Datadog Support](0009-datadog.md) 22 | * [0010: Rename Open Liberty buildpack to Liberty](0010-rename-open-liberty-buildpack.md) 23 | * [0011: Apache Tomee Buildpack](0011-apache-tomee.md) 24 | * [0012: Quarkus Buildpack](0012-quarkus.md) 25 | * [0013: OpenTelemetry Support](0013-opentelemetry.md) 26 | * [0014: Selecting the next default Java Version for Paketo Buildpacks](0014-selecting-default-java-version.md) 27 | 28 | ## Links 29 | 30 | * [Java Buildpack Docs](https://paketo.io/docs/buildpacks/language-family-buildpacks/java/) 31 | * [Java Native Image Buildpack Docs](https://paketo.io/docs/buildpacks/language-family-buildpacks/java-native-image/) 32 | -------------------------------------------------------------------------------- /text/0012-builder-subteam.md: -------------------------------------------------------------------------------- 1 | # Builders Subteam 2 | 3 | ## Summary 4 | 5 | The Builders are being separated out of the set of responsiblities of the Core 6 | Dependencies team. This means that a new subteam will need to be created to 7 | maintain the repositories under this responsibility. 8 | 9 | ## Motivation 10 | 11 | The existing Core Dependencies team is wishing to focus more directly on stacks 12 | and less on builders which a more directly a "buildpack concern". Having a set 13 | of maintainers and contributors from the existing buildpack subteams would help 14 | to better align this responsibility with those folks concerned. 15 | 16 | ## Detailed Explanation 17 | 18 | A new Builders subteam will take over maintenance of the existing [builder 19 | repository](https://github.com/paketo-buildpacks/builder) and any new 20 | repositories created under RFCs declared within that repo. 21 | 22 | As an initial proposal, there will be 2 maintainers, one from the Java team, 23 | and one from the other teams (@ekcasey and @floragj). All other individuals in 24 | either the maintainers or contributors team for each language family will be 25 | included as contributors for this new subteam. 26 | 27 | ## Rationale and Alternatives 28 | 29 | We could choose to maintain the status quo. 30 | 31 | ## Implementation 32 | 33 | 1. A "Builders" team should be created in the [paketo-buildpacks GitHub 34 | org](https://github.com/orgs/paketo-buildpacks/teams) with the designated 35 | maintainers. 36 | 1. All other maintainers or contributors for language family teams should be 37 | added as contributors. 38 | 1. The "Builders" team should be granted maintainer and contributor permissions 39 | to manage the [builder 40 | repository](https://github.com/paketo-buildpacks/builder). 41 | 42 | ## Unresolved Questions and Bikeshedding 43 | 44 | {{REMOVE THIS SECTION BEFORE RATIFICATION!}} 45 | -------------------------------------------------------------------------------- /text/stacks/0001-stack-package-metadata.md: -------------------------------------------------------------------------------- 1 | # Add io.paketo.stack.packages label 2 | 3 | ## Proposal 4 | 5 | We want to add a new label (io.paketo.stack.packages) to all stacks that contains a collection of metadata for all of the packages in the stack. 6 | 7 | ## Motivation 8 | 9 | This metadata will help users have a more accurate depiction of exactly what is in the stack. 10 | 11 | ## Implementation 12 | 13 | 14 | Schema: 15 | ```json 16 | "io.paketo.stack.packages": "[{ 17 | "name": "", 18 | "version": ">", 19 | "arch": ">", 20 | "summary": "", 21 | "sourcePackage": { 22 | "name": "", 23 | "version": "", 24 | "upstreamVersion": "" 25 | } 26 | }]" 27 | ``` 28 | 29 | Example: 30 | ```json 31 | "io.paketo.stack.packages": "[{ 32 | "name": "libc6", 33 | "version": "2.27-3ubuntu1.4", 34 | "arch": "amd64", 35 | "summary": "GNU C Library: Shared libraries", 36 | "sourcePackage": { 37 | "name": "glibc", 38 | "version": "2.27-3ubuntu1.4", 39 | "upstreamVersion": "2.27" 40 | } 41 | }]" 42 | ``` 43 | 44 | 45 | ## Unresolved Questions and Bikeshedding 46 | 47 | Is there a clearer/more accurate label name we can use? Technically "stack" refers to a pair of images but we're only trying to represent the packages on a single image. 48 | -------------------------------------------------------------------------------- /text/dependencies/rfcs/0001-dependency-server-licenses.md: -------------------------------------------------------------------------------- 1 | # Add License Field to the Dependency Server Metadata 2 | 3 | ## Summary 4 | 5 | Add a field for license information into the dependency server schema. 6 | This RFC is an addendum to [RFC 7 | #0009](https://github.com/paketo-buildpacks/rfcs/blob/main/text/0009-dep-server.md) 8 | 9 | ## Motivation 10 | 11 | Currently, the dependency server offers a lot of valuable information about the 12 | files it hosts. However, it currently does not have the capacity to supply 13 | license information. This field should be added to the dependency server 14 | because information about the license(s) of a dependency is a valuable and 15 | necessary piece of information for those that are trying to make sure that 16 | their apps use license that comply with their use cases. 17 | 18 | ## Implementation 19 | 20 | The following field should be added to the dependency server output: 21 | 22 | * `licenses`: an array of [SPDX license IDs](https://spdx.org/licenses/) that 23 | are used by the dependency 24 | 25 | An example of the new output: 26 | ``` 27 | $ curl -sL https://api.deps.paketo.io/v1/dependency?name=go 28 | [ 29 | { 30 | "name": "go", 31 | "version": "1.15", 32 | "sha256": "29d4ae84b0cb970442becfe70ee76ce9df67341d15da81b370690fac18111e63", 33 | "uri": "https://deps.paketo.io/go/go_1.15_linux_x64_bionic_29d4ae84.tgz", 34 | "stacks": [ 35 | { 36 | "id": "io.buildpacks.stacks.bionic" 37 | }, 38 | { 39 | "id": "io.paketo.stacks.tiny", 40 | "mixins": ["some-required-mixin"] 41 | } 42 | ], 43 | "source": "https://dl.google.com/go/go1.15.src.tar.gz", 44 | "source_sha256": "69438f7ed4f532154ffaf878f3dfd83747e7a00b70b3556eddabf7aaee28ac3a", 45 | "deprecation_date": "", 46 | "licenses": ["BSD-3-Clause"] 47 | } 48 | ] 49 | ``` 50 | 51 | ## Prior Art 52 | 53 | The Java buildpacks provide license information about the dependencies that 54 | they ingest. 55 | -------------------------------------------------------------------------------- /text/java/0010-rename-open-liberty-buildpack.md: -------------------------------------------------------------------------------- 1 | # Rename Open Liberty buildpack to Liberty 2 | 3 | ## Summary 4 | 5 | The `open-liberty` buildpack can utilize either the Open Liberty or Websphere Liberty runtime. To avoid confusion the buildpack should simply be named `liberty`. 6 | 7 | ## Motivation 8 | 9 | There are a few motivations for this change: 10 | 11 | 1. The open-liberty buildpack name is misleading because the buildpack can utilize Open Liberty or WebSphere Liberty. 12 | 2. Avoid confusion on the buildpack capabilities. 13 | 3. The buildpack has not been released as 1.0, and is not included in a composite buildpack or builder so a name change now will have minimal impact. 14 | 15 | ## Detailed Explanation 16 | 17 | [RFC 0031](https://github.com/paketo-buildpacks/rfcs/blob/main/text/0031-liberty-buildpack.md) indicated both Open Liberty and WebSphere Liberty would be available. The 18 | original `open-liberty` buildpack contributed by the community only contributed `Open Liberty`. We have since added support for WebSphere Liberty. 19 | 20 | 21 | ## Rationale and Alternatives 22 | 23 | Alternatives: 24 | 25 | - Do nothing. Users of the Open Liberty buildpack may not know WebSphere Liberty is available and we will need to repeatedly explains WebSphere Liberty is available. 26 | 27 | ## Implementation 28 | 29 | 1. Cut a release with the current name with any unreleased features in progress. 30 | 2. Make the name change 31 | 2a. Rename the `open-liberty` repo to `liberty`. 32 | 2b. Modify files (buildpack.toml, etc) and directories that reference open liberty. 33 | 3. Cut a new release with the new name. 34 | 35 | ## Prior Art 36 | 37 | - The Java-related buildpacks tend to pick names that represent the tool wrapped by the buildpack (Maven, Tomcat, Spring Boot, etc...). 38 | Dropping `open-` from the name keeps us in line with that naming strategy, in fact probably more accurately follows it. 39 | 40 | ## Unresolved Questions and Bikeshedding 41 | 42 | - None -------------------------------------------------------------------------------- /text/0007-buildpack-naming.md: -------------------------------------------------------------------------------- 1 | # Paketo Buildpack Naming 2 | 3 | ## Summary 4 | 5 | All Paketo buildpacks should be named in a consistent manner. Specifically, 6 | they should include a "Paketo" prefix before their identifier and include a 7 | "Buildpack" suffix. 8 | 9 | ## Motivation 10 | 11 | Providing a buildpack name that indicates that these buildpacks are part of the 12 | Paketo organization will help users to identify the provenance of the 13 | buildpacks running on their platform more easily. There are already offerings 14 | for buildpacks in similar runtimes from other organizations. Indicating that a 15 | buildpack comes from the Paketo organization will help to clear up any 16 | ambiguity. 17 | 18 | ## Detailed Explanation 19 | 20 | Taking an example of the "Node Engine" buildpack, the proper name would be 21 | "Paketo Node Engine Buildpack". This name should appear in the `buildpack.name` 22 | field within the `buildpack.toml` file. 23 | 24 | ## Rationale and Alternatives 25 | 26 | The obvious alternative is to let buildpack maintainers name their buildpacks 27 | independently. This will likely lead to confusion and is not recommended. 28 | 29 | ## Implementation 30 | 31 | Any buildpacks that do not follow the rules outlined above should be renamed to 32 | align with this RFC. 33 | 34 | ## Prior Art 35 | 36 | There are already an existing set of buildpacks within the Paketo community 37 | that conform to this naming pattern. Here is a subset of examples: 38 | 39 | - [Paketo Java Buildpack](https://github.com/paketo-buildpacks/java/blob/81ba7f4a1f1ba6b12ab4a1ccc97a8770e0b8023e/buildpack.toml#L19) 40 | - [Paketo Lein Buildpack](https://github.com/paketo-buildpacks/leiningen/blob/ce47f6864c6179efa44ad6247f353508c014b6d0/buildpack.toml#L5) 41 | - [Paketo Maven Buildpack](https://github.com/paketo-buildpacks/maven/blob/b3045bd346f696b3fe22f7942e20b4d4ada3eb57/buildpack.toml#L19) 42 | - [Paketo Spring Boot Native Image Buildpack](https://github.com/paketo-buildpacks/spring-boot-native-image/blob/164dfa4e115834241e07b684c328e40b2afcec5d/buildpack.toml#L19) 43 | -------------------------------------------------------------------------------- /text/java/0009-datadog.md: -------------------------------------------------------------------------------- 1 | # Datadog Support 2 | 3 | ## Summary 4 | 5 | The [Paketo Java Buildpack](https://github.com/paketo-buildpacks/java) presently supports the APM tools Google Stackdriver and Azure Application Insights. This RFC proposes we add support for Datadog as well. 6 | 7 | ## Motivation 8 | 9 | Datadog is a popular APM tool and monitoring platform. For Java applications, there was an [initial buildpack which instrumented applications with the Agent](https://github.com/DataDog/datadog-trace-paketo-buildpack), however, this is no longer being maintained. This initial buildpack proved that there is interest for Datadog support & this RFC proposes that we add an official Paketo buildpack. 10 | 11 | ## Detailed Explanation 12 | 13 | This RFC proposes the following changes: 14 | 15 | - Create a new buildpack, `paketo-buildpacks/datadog` 16 | - The buildpack will install the Datadog Agent & software required to report metrics to Datadog 17 | - The buildpack will adjust the JVM arguments to enable the Datadog agent 18 | - The initial target is for this buildpack to work with the JVM, however, it will be implemented in a way that integration with other language families is also possible similar to Google Stack Driver and Azure App Insights. 19 | 20 | ## Rationale and Alternatives 21 | 22 | Adds easy support for another popular APM tool/platform. We could not add the buildpack and then users would be left to configure this integration manually, which is not as nice of a user experience. 23 | 24 | ## Implementation 25 | 26 | 1. Create a new repo under `paketo-buildpacks/datadog` 27 | 2. Set owner as Paketo Java subteam 28 | 3. Push a skeleton project using libcnb/libpak 29 | 4. Implement the buildpack following the logic describes [here](https://github.com/DataDog/datadog-trace-paketo-buildpack) (Apache 2 license) 30 | 5. Update dependencies 31 | 6. Add standard set of CI jobs 32 | 7. Document usage 33 | 8. Publish initial release 34 | 35 | ## Prior Art 36 | 37 | - Google Stack Driver 38 | - Azure Application Insights 39 | 40 | ## Unresolved Questions and Bikeshedding 41 | 42 | - None 43 | -------------------------------------------------------------------------------- /text/0041-direct.md: -------------------------------------------------------------------------------- 1 | # Use Direct Processes and exec.d 2 | 3 | ## Summary 4 | 5 | This RFC proposes that we move all Paketo buildpacks to use `direct` process types and `exec.d` interface instead of `profile.d` interface and `direct = false` process types wherever possible without breaking backwards compatibility from an end user perspective. 6 | 7 | ## Motivation 8 | 9 | As of Buildpacks [RFC 0093](https://github.com/buildpacks/rfcs/blob/main/text/0093-remove-shell-processes.md) we plan on removing any shell specific logic from the lifecycle and instead have non-shell specific interfaces. In preperation for these changes, we should identify all Paketo buildpacks that rely on `profile.d` interface or use `direct = false` process types and convert them to `exec.d` interfaces and `direct = true` process types respectively. 10 | 11 | ## Detailed Explanation 12 | 13 | `direct = false` process types and `profile.d` interfaces have various drawbacks. 14 | 15 | - They are slower since they involve shell invocations 16 | - The argument parsing logic can be confusing 17 | - If a process is run with `direct = true` any and all `profile.d` scripts are NOT executed potentially causing issues and confusion around the behaviour of the final application image. 18 | 19 | Because of all of the reasons above and others listed in Buildpacks [RFC 0093](https://github.com/buildpacks/rfcs/blob/main/text/0093-remove-shell-processes.md), we should try to move away from any shell specific interfaces. 20 | 21 | ## Rationale and Alternatives 22 | 23 | Rationale per above. 24 | 25 | Alternatives - keep using shell specific interfaces until they are deprecated. 26 | 27 | ## Implementation 28 | 29 | The migration path should be relatively easy and most `profile.d` scripts can be easily turned into `exec.d` scripts. Some more details can be found [here](https://github.com/buildpacks/rfcs/blob/main/text/0093-remove-shell-processes.md#layerprofiled) 30 | 31 | ## Prior Art 32 | 33 | - Most libpak based buildpacks already use exec.d interfaces and `direct = true` process types. 34 | 35 | ## Unresolved Questions and Bikeshedding 36 | -------------------------------------------------------------------------------- /text/python/0004-pipenv-restructure.md: -------------------------------------------------------------------------------- 1 | # Restructure Pipenv Buildpack 2 | 3 | ## Proposal 4 | 5 | The existing Pipenv buildpack should be rewritten and restructured to *only* 6 | provide the `pipenv` dependency. Any app dependency installation logic should 7 | be removed. 8 | 9 | ## Motivation 10 | 11 | In keeping with the overarching [Python Buildpack Rearchitecture 12 | RFC](https://github.com/paketo-community/python/blob/main/rfcs/0001-restructure.md), 13 | the Pipenv Buildpack should perform one task, which is installing the `pipenv` 14 | dependency. This is part of the effort in Paketo Buildpacks to reduce the 15 | responsibilities of each buildpack to make them easier to understand and 16 | maintain. 17 | 18 | ## Implementation 19 | 20 | ### API 21 | 22 | provides: `pipenv` requires: `cpython` and `pip` during build 23 | 24 | ### Detection 25 | 26 | The buildpack will always pass detection. 27 | 28 | ### Configuration 29 | 30 | #### BP_PIPENV_VERSION 31 | 32 | Users may specify a Pipenv version through the `BP_PIPENV_VERSION` environment 33 | variable. This can be set explicitly at build time (e.g. `pack --env`) or 34 | through `project.toml`. 35 | 36 | ### Dependency Installation 37 | 38 | During the build phase, pipenv installation proceeds as outlined below: 39 | 40 | Using the pip installation from the preceding `pip` buildpack, the buildpack 41 | downloads the selected Pipenv dependency and extracts it into a temporary 42 | directory (`path/to/pipenv/dependency`). 43 | 44 | `PYTHONUSERBASE= pip install pipenv --user 45 | --find-links=` is run to install the requested 46 | version. 47 | Setting the `PYTHONUSERBASE` variable ensures that pipenv is installed to the newly created layer. 48 | 49 | Once the installation is complete, the buildpack prepends the 50 | `layers//lib/python/site-packages` to the `PYTHONPATH` 51 | environment variable and export it as a shared environment variable for 52 | downstream buildpacks. This is necessary so Python looks for `pipenv` in the 53 | pipenv layer, instead of the default location. 54 | 55 | -------------------------------------------------------------------------------- /text/stacks/0007-squash-stack.md: -------------------------------------------------------------------------------- 1 | # Squash Stack Images 2 | 3 | ## Summary 4 | 5 | The build and run images delivered as a stack for our users should each be 6 | squashed into a single layer to reduce the total number of layers in the 7 | builder and application images and remove duplicated files that appear in 8 | multiple layers. 9 | 10 | ## Motivation 11 | 12 | Stack images act as the base image for applications and our own builder images. 13 | Their internal layer implementations should not be important to end users. 14 | Recently, we have been fielding a lot of bug reports wherein users cannot 15 | create their application images because the total number of layers for the 16 | image has exceeded the limit enforced by `containerd`. 17 | 18 | Squashing each stack image down into a single layer will create more headroom 19 | for both the builders and the images they create. 20 | 21 | ## Detailed Explanation 22 | 23 | The `jam create-stack` command will include a new flag, `--squash`, that will 24 | squash the build and run image layers each into a single layer. These squashed 25 | images will be what the project ships as the canonical stack images for Bionic 26 | and Jammy. 27 | 28 | ## Rationale and Alternatives 29 | 30 | As an alternative, we could choose to add this functionality to `jam 31 | create-stack`, but not use it as the default for the stack we ship, but allow 32 | those with layer limit issues to squash the stacks themselves. 33 | 34 | ## Implementation 35 | 36 | The [`crane` 37 | CLI](https://github.com/google/go-containerregistry/tree/main/cmd/crane) has a 38 | `flatten` command that does [this exact 39 | operation](https://github.com/google/go-containerregistry/blob/1711cefd7eec057d3892d0bbce1bcd3f8c46d606/cmd/crane/cmd/flatten.go#L201-L254), 40 | but against an image hosted already on a registry. We can reference this 41 | existing code as a starting point for our own implementation that would operate 42 | against an image as implemented within `jam create-stack`. 43 | 44 | ## Prior Art 45 | 46 | * [`crane flatten`](https://github.com/google/go-containerregistry/blob/main/cmd/crane/doc/crane_flatten.md) 47 | -------------------------------------------------------------------------------- /text/java/0002-alibaba-jdk.md: -------------------------------------------------------------------------------- 1 | # Paketo Buildpacks Alibaba Dragonwell Buildpack 2 | 3 | ## Summary 4 | 5 | A [Alibaba Dragonwell Buildpack](https://github.com/eddumelendez/dragonwell) for supplying Alibaba's distribution of OpenJDK has been created by [@eddumelendez][@eddumelendez]. It is built using common tooling (libpak and libjvm) used by the Paketo Java sub-team and should be adopted into the Paketo Buildpacks Github Org. 6 | 7 | ## Motivation 8 | 9 | We would like to move the Alibaba Dragonwell Buildpack into Paketo Buildpacks so that the community can use it to build Java applications, in particular on Alibaba Cloud. This will also give the buildpack maintainer the ability to leverage common Paketo tooling to keep the buildpack dependencies updated and release the buildpack. 10 | 11 | ## Detailed Explanation 12 | 13 | N/A 14 | 15 | ## Rationale and Alternatives 16 | 17 | N/A 18 | 19 | ## Implementation 20 | 21 | The Alibaba Dragonwell Buildpack will be moved into the `paketo-buildpacks` Github organization and added to the Java sub-team. Maintainenance for this buildpack will be provided by the Java subteam. 22 | 23 | The following changes will be made: 24 | 25 | - [Alibaba Dragonwell Buildpack](https://github.com/eddumelendez/dragonwell) moved to Paketo Buildpacks org 26 | - Buildpack will have `paketo-buildpacks/alibaba-dragonwell` ID 27 | - Buildpack will be published to `gcr.io/paketo-buildpacks/alibaba-dragonwell` 28 | - Buildpack will have go module of `github.com/paketo-buildpacks/alibaba-dragonwell` 29 | - Github Actions will be added through [pipeline-builder](https://github.com/paketo-buildpacks/pipeline-builder) 30 | - An action will be added to [pipeline-builder](https://github.com/paketo-buildpacks/pipeline-builder/tree/main/actions) with the purpose of checking for new versions of Alibaba's Dragonwell OpenJDK 31 | 32 | ## Prior Art 33 | 34 | [Leiningen Buildpack](https://github.com/paketo-buildpacks/rfcs/blob/master/accepted/0004-clojure.md) 35 | [Rust Buildpack](https://github.com/paketo-buildpacks/rfcs/blob/master/accepted/0014-rust.md) 36 | 37 | ## Unresolved Questions and Bikeshedding 38 | 39 | N/A 40 | -------------------------------------------------------------------------------- /text/java/0001-microsoft-jdk.md: -------------------------------------------------------------------------------- 1 | # Paketo Buildpacks Microsoft OpenJDK Buildpack 2 | 3 | ## Summary 4 | 5 | A [Microsoft OpenJDK Buildpack](https://github.com/eddumelendez/microsoft-openjdk) for supplying Microsoft's distribution of OpenJDK has been created by [@eddumelendez][@eddumelendez]. It is built using common tooling (libpak and libjvm) used by the Paketo Java sub-team and should be adopted into the Paketo Buildpacks Github Org. 6 | 7 | ## Motivation 8 | 9 | We would like to move the Microsoft OpenJDK Buildpack into the Paketo Buildpacks org so that the community can use it to build Java applications, in particular on Microsoft Azure. This will also give the buildpack maintainer the ability to leverage common Paketo tooling to keep the buildpack dependencies updated and release the buildpack. 10 | 11 | ## Detailed Explanation 12 | 13 | N/A 14 | 15 | ## Rationale and Alternatives 16 | 17 | N/A 18 | 19 | ## Implementation 20 | 21 | The Microsoft OpenJDK Buildpack will be moved into the `paketo-buildpacks` Github organization and added to the Java sub-team. Maintainenance for this buildpack will be provided by the Java subteam. 22 | 23 | The following changes will be made: 24 | 25 | - [Microsoft OpenJDK Buildpack](https://github.com/eddumelendez/microsoft-openjdk) moved to Paketo Buildpacks org 26 | - Buildpack will have `paketo-buildpacks/microsoft-openjdk` ID 27 | - Buildpack will be published to `gcr.io/paketo-buildpacks/microsoft-openjdk` 28 | - Buildpack will have go module of `github.com/paketo-buildpacks/microsoft-openjdk` 29 | - Github Actions will be added through [pipeline-builder](https://github.com/paketo-buildpacks/pipeline-builder) 30 | - An action will be added to [pipeline-builder](https://github.com/paketo-buildpacks/pipeline-builder/tree/main/actions) with the purpose of checking for new versions of Microsoft OpenJDK 31 | 32 | ## Prior Art 33 | 34 | [Leiningen Buildpack](https://github.com/paketo-buildpacks/rfcs/blob/master/accepted/0004-clojure.md) 35 | [Rust Buildpack](https://github.com/paketo-buildpacks/rfcs/blob/master/accepted/0014-rust.md) 36 | 37 | ## Unresolved Questions and Bikeshedding 38 | 39 | N/A 40 | -------------------------------------------------------------------------------- /text/tooling/0001-extract-jam-from-packit.md: -------------------------------------------------------------------------------- 1 | # Extract `jam` into Dedicated Repository 2 | 3 | ## Proposal 4 | 5 | Currently, the source for the `jam` cli tool resides inside of the 6 | `cargo` package which itself is inside of the `packit` repository. All `jam` 7 | source code should be extracted from its current location and be relocated into 8 | its own repository. 9 | 10 | ## Motivation 11 | 12 | Initially `jam` was placed inside of the `packit` repository because it was the 13 | dedicated packaging tool for buildpacks that are written in `packit`. However, 14 | its functions have expanded beyond just packaging `packit` buildpacks and now 15 | encompass a wide variety of functions such as: 16 | * Summarizing the contents of a buildpackage 17 | * Updating `builder.toml` files 18 | * Updating metabuildpack `buildpack.toml` dependencies 19 | 20 | All of these are generic functions that could work with any buildpack 21 | regardless of whether or not it is written using `packit`. 22 | 23 | By extracting the `jam` cli, a number of positives can be achieved: 24 | * The version of `packit` and `jam` are no longer interlocked making the 25 | releases of both more SemVerically sound 26 | * It will clean up the `packit` codebase of any code that is not api or helper 27 | * It will make `jam` more discoverable and we could potentially expand `jam` 28 | into a much more useful and universal buildpacks development tool for authors 29 | in the buildpacks community 30 | 31 | ## Implementation 32 | 33 | A new repository should be created that is owned by the tooling maintainers 34 | named `jam`. Then all `jam` source code should be moved into this repository 35 | from `packit`. Once that is complete and a release has been cut, all scripts 36 | that currently download `jam` need to be updated in order to download `jam` 37 | from it's new release home. A message should be added to the `packit` README 38 | that the `jam` release has been moved to a new repository. 39 | 40 | ## Unresolved Questions and Bikeshedding 41 | 42 | * How long should that redirect message remain present on the README for 43 | `packit`? 44 | 45 | {{REMOVE THIS SECTION BEFORE RATIFICATION!}} 46 | -------------------------------------------------------------------------------- /text/nodejs/0015-dependencies.md: -------------------------------------------------------------------------------- 1 | # Decide which `nodejs` dependencies will be Paketo-hosted 2 | 3 | ## Proposal 4 | 5 | The following dependencies should be removed as Paketo-hosted dependencies: 6 | * [yarn](https://github.com/paketo-buildpacks/yarn/blob/main/buildpack.toml) 7 | * [cycloneDX (node-module-bom)](https://github.com/paketo-buildpacks/node-module-bom/blob/main/buildpack.toml) 8 | 9 | The following dependency should be Paketo-hosted for bionic only and pulled directly from upstream for jammy 10 | * [node-engine](https://github.com/paketo-buildpacks/node-engine/blob/main/buildpack.toml) 11 | 12 | ## Rationale 13 | 14 | ### node-engine 15 | 16 | Keep the bionic dependency as a Paketo-hosted dependency only and pull jammy from upstream 17 | 18 | The Paketo node-engine buildpack supports using the system's CA store, which is not a default feature in node. 19 | This feature is currently enabled by compiling node from source with the `--openssl-use-def-ca-store` flag. 20 | But it can also be enabled by setting `NODE_OPTIONS` to `--use-openssl-ca`. 21 | Node can be pulled directly from upstream for jammy. 22 | However, versions 18+ are not compatible with bionic without compiling from source. 23 | Therefore, this RFC proposes making the bionic dependency a Paketo-hosted dependency 24 | and pulling the jammy dependency directly from upstream. 25 | 26 | ### yarn 27 | 28 | Remove the Paketo-hosted dependency. 29 | 30 | It looks like yarn is downloaded directly from a [Github release url](https://github.com/paketo-buildpacks/dep-server/blob/7098d1969b374b03da1d7cd4b5ca53596609a646/pkg/dependency/yarn.go#L109). 31 | This may be replicated in the buildpack's `build` stage if the top level tar file directory can be removed. Therefore, this RFC proposes removing yarn as a Paketo-hosted dependency. 32 | 33 | ### cycloneDX (node-module-bom) 34 | 35 | Remove the Paketo-hosted dependency. 36 | 37 | The node-module-bom Paketo buildpack installs the [CycloneDX Node Module 38 | tool](https://github.com/CycloneDX/cyclonedx-node-module) into a layer. While this dependency is currently a Paketo-hosted 39 | dependency, it could also be installed using the `npm` cli. 40 | Therefore, this RFC proposes removing cycloneDX as a Paketo-hosted dependency. 41 | -------------------------------------------------------------------------------- /text/java/0005-clojure-tools.md: -------------------------------------------------------------------------------- 1 | # Clojure Tools Buildpack 2 | 3 | ## Summary 4 | 5 | A Clojure Tools buildpack for building Clojure applications using [deps][d] and [tools build][t] has been created [by the community][b]. It is based on the same technologies and is nearly indistinguishable from the other Paketo Buildpacks, especially the JVM build-system buildpacks, and it should be adopted into the project. 6 | 7 | [d]: https://clojure.org/guides/deps_and_cli 8 | [t]: https://clojure.org/guides/tools_build 9 | [b]: https://github.com/eddumelendez/clojure 10 | 11 | ## Motivation 12 | 13 | This is an additional buildpack, for building JVM-based applications based on Clojure, and offers yet another workload that can be built by Paketo buildpacks. 14 | 15 | ## Detailed Explanation 16 | 17 | The Clojure Tools Buildpack will be moved into the paketo-buildpacks Github organization and added to the Java sub-team. Maintenance for this buildpack will be provided by the Java subteam. 18 | 19 | The following changes will be made: 20 | 21 | * [Clojure Tools Buildpack][b] moved to Paketo Buildpacks org 22 | * Buildpack will have paketo-buildpacks/clojure-tools ID 23 | * Buildpack will be published to gcr.io/paketo-buildpacks/clojure-tools 24 | * Buildpack will have go module of github.com/paketo-buildpacks/clojure-tools 25 | * Github Actions will be added through [pipeline-builder][p] 26 | * An action will be added to [pipeline-builder][p] with the purpose of checking for new versions of [Clojure Tools][c] 27 | * Following existing conventions, the action will truncate the version of Clojure Tools to a three part semver (e.g. `1.10.3.943` becomes `1.10.3`). In the future, this may change if pipeline-builder and libpak are enhanced to sanely handle a wider range of version formats. 28 | 29 | [b]: https://github.com/eddumelendez/clojure 30 | [p]: https://github.com/paketo-buildpacks/pipeline-builder 31 | [c]: https://clojure.org/releases/tools 32 | 33 | ## Rationale and Alternatives 34 | 35 | N/A 36 | 37 | ## Implementation 38 | 39 | This buildpack will be adopted by the Java Buildpacks team and transferred to the `paketo` GitHub organization. The original author will be added as a contributor to the Java subteam. 40 | 41 | ## Prior Art 42 | 43 | N/A 44 | 45 | ## Unresolved Questions and Bikeshedding 46 | 47 | N/A 48 | -------------------------------------------------------------------------------- /text/web-servers/0006-dependencies.md: -------------------------------------------------------------------------------- 1 | # Decide which `web-server` dependencies will be Paketo-hosted 2 | 3 | ## Proposal 4 | 5 | The following dependencies should be kept as Paketo-hosted dependencies: 6 | * [nginx](https://github.com/paketo-buildpacks/nginx/blob/main/buildpack.toml) 7 | * [httpd](https://github.com/paketo-buildpacks/httpd/blob/main/buildpack.toml) 8 | 9 | ## Rationale 10 | 11 | ### nginx 12 | 13 | Keep this as a Paketo-hosted dependency. 14 | 15 | The nginx server has many different features that are not enabled by default in an upstream binary. To enable specific 16 | nginx features, nginx must be compiled from source using its `configure` script with the appropriate options. For example, 17 | to enable debug logging, the `configure` script has to run using the `--with-debug` option. Since the nginx buildpack supports 18 | several non-default features, this RFC does not propose removing nginx as a Paketo-hosted dependency. All the features that are 19 | currently included in the Paketo nginx dependency can be found [here](https://github.com/cloudfoundry/buildpacks-ci/blob/0feb3c1ffd58d9021f3edf2988833d6265db5a23/tasks/build-binary-new/builder.rb#L320). 20 | 21 | Currently nginx uses `dep-server`, `binary-builder`, and `buildpacks-ci` to build, but language family maintainers 22 | will transition this to the new Github Action workflow once that has been approved. 23 | 24 | ### httpd 25 | 26 | Keep this as a Paketo-hosted dependency. 27 | 28 | Similar to the nginx server, the httpd server is customizable and several features are not included by default in httpd upstream binaries. 29 | In addition, [Apache's site](https://httpd.apache.org/docs/2.4/install.html#page-header) states that "binary releases are often not up 30 | to date with the latest source releases" and recommends compiling from source. Therefore, this RFC does not propose removing httpd as a 31 | Paketo-hosted dependency. All the features that are currently included in the Paketo httpd dependency can be found [here](https://github.com/cloudfoundry/binary-builder/blob/543c706d05f0245f476f47c7add22fbb35758761/recipe/httpd_meal.rb#L41). 32 | 33 | Currently httpd uses `dep-server`, `binary-builder`, and `buildpacks-ci` to build, but language family maintainers 34 | will transition this to the new Github Action workflow once that has been approved. 35 | -------------------------------------------------------------------------------- /text/stacks/0002-add-libz.md: -------------------------------------------------------------------------------- 1 | # Add libz to the Tiny Run Image 2 | 3 | ## Summary 4 | 5 | At the moment, Java applications do not run on the tiny builder. It is possible to build them, however, if you try to run one you'll end up with an error. 6 | 7 | ```bash 8 | > docker run apps/maven 9 | Setting Active Processor Count to 6 10 | Calculating JVM memory based on 9029088K available memory 11 | Calculated JVM Memory Configuration: -XX:MaxDirectMemorySize=10M -Xmx8633478K -XX:MaxMetaspaceSize=88409K -XX:ReservedCodeCacheSize=240M -Xss1M (Total Memory: 9029088K, Thread Count: 50, Loaded Class Count: 13195, Headroom: 0%) 12 | Adding 129 container CA certificates to JVM truststore 13 | Spring Cloud Bindings Enabled 14 | java: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory 15 | ``` 16 | 17 | The tiny run image is missing `libz`. 18 | 19 | ## Motivation 20 | 21 | To support running Java applications with the tiny builder. 22 | 23 | This should be feasible and desirable as most Java applications do not have external OS level dependencies. This can reduce the size of an app image by roughly 70M. 24 | 25 | ```bash 26 | apps/maven-tiny latest 62b31d663f4d 41 years ago 195MB 27 | apps/maven-base latest d603b38c0af0 41 years ago 268MB 28 | ``` 29 | 30 | ## Detailed Explanation 31 | 32 | Install the `zlib1g` package for the Ubuntu based tiny run image. It looks like this will [add 169.0 kB to the image size](https://packages.ubuntu.com/bionic/zlib1g). 33 | 34 | ## Rationale and Alternatives 35 | 36 | 1. Java buildpacks would need to install libz. This is one additional step which is required and puts the burden of supplying OS dependencies on the Java buildpack, including updates for security & bug fixes to libz. 37 | 38 | 2. Mix-ins + [Stack Buildpacks](https://github.com/buildpacks/rfcs/blob/main/text/0069-stack-buildpacks.md). This seems like a good solution, but it doesn't exist yet and it's not clear when this will happen. When this is implemented, perhaps we can revert this addition and use this as a solution. 39 | 40 | ## Implementation 41 | 42 | Install the `zlib1g` package for the Ubuntu based tiny run image. 43 | 44 | ## Prior Art 45 | 46 | None 47 | 48 | ## Unresolved Questions and Bikeshedding 49 | 50 | - Is it OK to add a library to Tiny? We don't have a policy to dictate what is suitable. 51 | -------------------------------------------------------------------------------- /text/0025-emeritus-status.md: -------------------------------------------------------------------------------- 1 | # Establishing an Emeritus Status 2 | 3 | ## Summary 4 | 5 | The current governance rules outline roles for Contributors, Maintainers, and 6 | Steering Committee members. As the Paketo project has grown and evolved, 7 | contributors, maintainers, and steering committee members have come and gone. 8 | While the current governance rules do outline how those folks might resign or 9 | be removed from their positions, we'd like to establish a third option, 10 | retirement. In the case that a member of one of these teams is found to have 11 | retired from the project, they will be an emeritus position at their 12 | current role title. 13 | 14 | ## Motivation 15 | 16 | We'd like a way to prune the set of folks with elevated permissions on the 17 | project while still acknowledging the work done by these individuals. We can 18 | remove inactive individuals with the current governance rules, but we'd also 19 | like to recognize their contributions to the project. 20 | 21 | ## Detailed Explanation 22 | 23 | This RFC will function as an addendum to [RFC 0002](./0002-governance.md). For 24 | each role defined in that RFC, we will establish a retirement clause stating 25 | that individuals may retire and accept an emeritus title at their current role 26 | title for any subteam. Functionally, the emeritus title is purely honorific and 27 | imbues the holder with no voting status or permissions for that subteam. 28 | 29 | ## Rationale and Alternatives 30 | 31 | We could keep the current rules and provide no emeritus title. 32 | 33 | ## Implementation 34 | 35 | A subteam contributor or maintainer, or steering committee member can retire by 36 | sending notice to either a subteam maintainer, or a steering committee member. 37 | 38 | Alternatively, a contributor or maintainer may be retired by a supermajority 39 | vote from the subteam maintainers. This is similar to a vote to remove that 40 | contributor or maintainer, but also confers the retiree with the emeritus 41 | title. Steering committee members can also be retired, but with a 42 | supermajority vote from the existing steering committee membership. 43 | 44 | Once retired, the retiree will be granted with an emeritus title. They will 45 | also be removed from their current role in GitHub teams and their new title 46 | will be recorded in the [teams 47 | roster](https://github.com/paketo-buildpacks/community/blob/main/TEAMS.md) on 48 | the community repository. 49 | -------------------------------------------------------------------------------- /text/java/0015-composite-draft-branch.md: -------------------------------------------------------------------------------- 1 | # Create a draft branch for composite/meta buildpacks 2 | 3 | ## Summary 4 | 5 | Currently component buildpack bumps are created as PRs against the main branch, e.g. see [here](https://github.com/paketo-buildpacks/java/pull/873). 6 | This RFC proposes changing the CI to create these dependency bumps as commits to a PR against a new branch, e.g. `draft`. 7 | 8 | ## Motivation 9 | 10 | This will allow us to achieve the following improvements: 11 | 12 | 1. Auto-merging of component buildpack PRs into this draft branch 13 | 2. Manual review can be performed with a single PR before merging to main 14 | 2. Integration tests can be run on merging to main ensuring all changes in the release are covered 15 | 16 | ## Detailed Explanation 17 | 18 | Currently the component dependency PRs must be manually approved and merged separately, even though their changes do not cause merge conflicts. Auto-merging these will reduce the maintainence burden involved here. 19 | Integration tests can configured to run on merges to the main branch, which could happen once per week before a release, or more frequently if necessary for a specific purpose. 20 | 21 | ## Rationale and Alternatives 22 | 23 | 1. Do not change the current CI/branch configuration - integration tests could be run via a manual step before release. 24 | 2. Do not change the current CI/branch configuration - create new release tags as a separate initial step before a release is published. Integration tests could be run on tag creation instead, with the publish action potentially triggered from passed tests. 25 | 26 | ## Implementation 27 | 28 | For the composite/meta buildpack repositories: 29 | 30 | 1. The pipeline-builder CI workflow step that updates package [dependencies](https://github.com/paketo-buildpacks/pipeline-builder/blob/main/octo/package_dependencies.go) would be changed to checkout a draft branch rather than the default of main. The PR for containing the update would then be created targeting this branch. 31 | 2. We would likely need a new workflow which triggers on merges to the 'draft' branch and opens/updates a PR to merge the dependency changes into main. The integration tests could be triggered here also. 32 | 33 | ## Prior Art 34 | 35 | This is how `buildpack.toml` is updated in non-Java composite buildpacks, see [this PR](https://github.com/paketo-buildpacks/python/pull/555/files) 36 | 37 | ## Unresolved Questions and Bikeshedding 38 | 39 | N/A 40 | -------------------------------------------------------------------------------- /text/go/go-dist/0001-buildpack-yml-to-env-var.md: -------------------------------------------------------------------------------- 1 | # Buildpack.yml to Environment Variables 2 | 3 | ## Proposal 4 | 5 | Migrate to using environment variables to do all buildpack configuration and 6 | get rid of `buildpack.yml`. 7 | 8 | ## Motivation 9 | 10 | There are several reasons for making this switch. 11 | 1. There is already an [existing RFC](https://github.com/paketo-buildpacks/rfcs/blob/b885abe5fe0b8f64def4a79f0952b7050f3bee6f/accepted/0003-replace-buildpack-yml.md) that proposes moving away from `buildpack.yml` as a configuration tool. 12 | 1. Environment variables appears to be the standard for configuration in other 13 | buildpack ecosystems such as Google Buildpacks and Heroku as well as the 14 | Paketo Java buildpacks. Making this change will align the buildpack with the 15 | rest of the buildpack ecosystem. 16 | 1. There is native supportto pass environment variables to the buildpack 17 | either on a per run basis or by configuration that can be checked into 18 | source control, in the form of `project.toml`. 19 | 20 | ## Implementation 21 | The proposed environment variables for Go Dist are as follow: 22 | 23 | #### BP_GO_VERSION 24 | ```shell 25 | $BP_GO_VERSION="1.14.1" 26 | ``` 27 | This will replace the following structure in `buildpack.yml`: 28 | ```yaml 29 | go: 30 | version: 1.14.1 31 | ``` 32 | 33 | ### Deprecation Strategy 34 | In order to facilitate a smooth transition from `buildpack.yml`, the buildpack 35 | should will support both configuration options with environment variables 36 | taking priority or `buildpack.yml` until the 1.0 release of the buildpack. The 37 | buildpack will detect whether or not the application has a `buildpack.yml` and 38 | print a warning message which will include links to documentation on how to 39 | upgrade and how to run builds with environment variable configuration. After 40 | 1.0, having a `buildpack.yml` will cause a detection failure and with a link to 41 | the same documentation. This behavior will only last until the next minor 42 | release of the buildpack after which point there will no longer be and error 43 | but `buildpack.yml` will not be supported. 44 | 45 | ## Source Material 46 | * [Google buildpack configuration](https://github.com/GoogleCloudPlatform/buildpacks#language-idiomatic-configuration-options) 47 | * [Paketo Java configuration](https://paketo.io/docs/buildpacks/language-family-buildpacks/java) 48 | * [Heroku configuration](https://github.com/heroku/java-buildpack#customizing) 49 | -------------------------------------------------------------------------------- /text/0043-reproducible-builds.md: -------------------------------------------------------------------------------- 1 | # Expanding the Criteria for Reproducible Builds 2 | 3 | ## Summary 4 | 5 | Given the same set of inputs and without leveraging caching, Paketo buildpacks 6 | should reproducibly build images. 7 | 8 | ## Motivation 9 | 10 | The current set of Paketo buildpacks do a reasonably good job of helping 11 | developers to ship reproducible build artifacts. They reuse layers where 12 | possible, and don't modify files in ways that aren't reproducible. So, for 13 | users taking advantage of the caching behaviors of CNBs, the reproducible build 14 | story is largely solved. 15 | 16 | However, we can do better in some other cases. Specifically, given a codebase 17 | that is not changing, a set of buildpacks that are not changing, and stacks 18 | that are not changing, we should be able to reproduce the exact same image on 19 | subsequent runs without leveraging the caching features of CNB. 20 | 21 | Unfortunately, there are some cases where we've made choices that prevent this 22 | type of reproducible build. These cases should be removed or minimized to the 23 | greatest extent possible. 24 | 25 | ## Detailed Explanation 26 | 27 | Many of the buildpacks contain behavior that results in non-reproducible images 28 | due to how they treat layer metadata. Specifically, they include a `built_at` 29 | metadata field that includes a timestamp for the instant that this layer was 30 | built. 31 | 32 | Including this type of field means that two subsequent runs of a build with 33 | identical inputs will produce different images. 34 | 35 | ## Alternatives 36 | 37 | Alternatively, we could assert that Paketo buildpacks will not be making an 38 | effort to enable this type of reproducible build. However, this path doesn't 39 | seem reasonable. Supporting these types of reproducible builds is obviously 40 | possible given different choices that are not fundamental to the value 41 | proposition of buildpacks. 42 | 43 | ## Implementation 44 | 45 | We should remove the `built_at` fields from all buildpack layers that include 46 | them. In our test suites that leverage this field to assert layer reuse, we 47 | should instead prefer to compare layer SHA values across rebuilds. 48 | 49 | We could also include new integration testing of this specific type of 50 | reproducible build scenario. 51 | 52 | ## Unresolved Questions and Bikeshedding 53 | 54 | * How do we handle versioning of buildpacks that remove this layer metadata 55 | field? Is this part of the public API? 56 | -------------------------------------------------------------------------------- /text/web-servers/0001-nginx-buildpack-yml-to-env-var.md: -------------------------------------------------------------------------------- 1 | # Buildpack.yml to Environment Variables 2 | 3 | ## Proposal 4 | 5 | Migrate to using environment variables to do all buildpack configuration and 6 | get rid of `buildpack.yml`. 7 | 8 | ## Motivation 9 | 10 | There are several reasons for making this switch. 11 | 1. There is already an [existing RFC](https://github.com/paketo-buildpacks/rfcs/blob/b885abe5fe0b8f64def4a79f0952b7050f3bee6f/accepted/0003-replace-buildpack-yml.md) that proposes moving away from `buildpack.yml` as a configuration tool. 12 | 1. Environment variables appears to be the standard for configuration in other 13 | buildpack ecosystems such as Google Buildpacks and Heroku as well as the 14 | Paketo Java buildpacks. Making this change will align the buildpack with the 15 | rest of the buildpack ecosystem. 16 | 1. There is native support to pass environment variables to the buildpack 17 | either on a per run basis or by configuration that can be checked into 18 | source control, in the form of `project.toml`. 19 | 20 | ## Implementation 21 | The proposed environment variables for NGINX are as follow: 22 | 23 | #### BP_NGINX_VERSION 24 | ```shell 25 | $BP_NGINX_VERSION="1.17.9" 26 | ``` 27 | This will replace the following structure in `buildpack.yml`: 28 | ```yaml 29 | nginx: 30 | version: 1.17.9 31 | ``` 32 | 33 | ### Deprecation Strategy 34 | In order to facilitate a smooth transition from `buildpack.yml`, the buildpack 35 | should will support both configuration options with environment variables 36 | taking priority or `buildpack.yml` until the 1.0 release of the buildpack. The 37 | buildpack will detect whether or not the application has a `buildpack.yml` and 38 | print a warning message which will include links to documentation on how to 39 | upgrade and how to run builds with environment variable configuration. After 40 | 1.0, having a `buildpack.yml` will cause a detection failure and with a link to 41 | the same documentation. This behavior will only last until the next minor 42 | release of the buildpack after which point there will no longer be and error 43 | but `buildpack.yml` will not be supported. 44 | 45 | ## Source Material 46 | * [Google buildpack configuration](https://github.com/GoogleCloudPlatform/buildpacks#language-idiomatic-configuration-options) 47 | * [Paketo Java configuration](https://paketo.io/docs/buildpacks/language-family-buildpacks/java) 48 | * [Heroku configuration](https://github.com/heroku/java-buildpack#customizing) 49 | -------------------------------------------------------------------------------- /text/web-servers/0002-httpd-buildpack-yml-to-env-var.md: -------------------------------------------------------------------------------- 1 | # Buildpack.yml to Environment Variables 2 | 3 | ## Proposal 4 | 5 | Migrate to using environment variables to do all buildpack configuration and 6 | get rid of `buildpack.yml`. 7 | 8 | ## Motivation 9 | 10 | There are several reasons for making this switch. 11 | 1. There is already an [existing 12 | RFC](https://github.com/paketo-buildpacks/rfcs/blob/b885abe5fe0b8f64def4a79f0952b7050f3bee6f/accepted/0003-replace-buildpack-yml.md) 13 | that proposes moving away from `buildpack.yml` as a configuration tool. 14 | 1. Environment variables appears to be the standard for configuration in other 15 | buildpack ecosystems such as Google Buildpacks and Heroku as well as the 16 | Paketo Java buildpacks. Making this change will align the buildpack with the 17 | rest of the buildpack ecosystem. 18 | 1. There is native support to pass environment variables to the buildpack 19 | either on a per run basis or by configuration that can be checked into 20 | source control, in the form of `project.toml`. 21 | 22 | ## Implementation 23 | The proposed environment variables for HTTPD are as follow: 24 | 25 | #### BP_HTTPD_VERSION 26 | ```shell 27 | $BP_HTTPD_VERSION="2.4.43" 28 | ``` 29 | This will replace the following structure in `buildpack.yml`: 30 | ```yaml 31 | httpd: 32 | version: 2.4.43 33 | ``` 34 | 35 | ### Deprecation Strategy 36 | In order to facilitate a smooth transition from `buildpack.yml`, the buildpack 37 | should will support both configuration options with environment variables 38 | taking priority or `buildpack.yml` until the 1.0 release of the buildpack. The 39 | buildpack will detect whether or not the application has a `buildpack.yml` and 40 | print a warning message which will include links to documentation on how to 41 | upgrade and how to run builds with environment variable configuration. After 42 | 1.0, having a `buildpack.yml` will cause a detection failure and with a link to 43 | the same documentation. This behavior will only last until the next minor 44 | release of the buildpack after which point there will no longer be and error 45 | but `buildpack.yml` will not be supported. 46 | 47 | ## Source Material 48 | * [Google buildpack configuration](https://github.com/GoogleCloudPlatform/buildpacks#language-idiomatic-configuration-options) 49 | * [Paketo Java configuration](https://paketo.io/docs/buildpacks/language-family-buildpacks/java) 50 | * [Heroku configuration](https://github.com/heroku/java-buildpack#customizing) 51 | -------------------------------------------------------------------------------- /text/python/0002-cpython-buildpack-yml-to-env-var.md: -------------------------------------------------------------------------------- 1 | # Buildpack.yml to Environment Variables 2 | 3 | ## Proposal 4 | 5 | Migrate to using environment variables to do all buildpack configuration and 6 | get rid of `buildpack.yml`. 7 | 8 | ## Motivation 9 | 10 | There are several reasons for making this switch. 11 | 1. There is already an [existing 12 | RFC](https://github.com/paketo-buildpacks/rfcs/blob/b885abe5fe0b8f64def4a79f0952b7050f3bee6f/accepted/0003-replace-buildpack-yml.md) 13 | that proposes moving away from `buildpack.yml` as a configuration tool. 14 | 1. Environment variables appears to be the standard for configuration in other 15 | buildpack ecosystems such as Google Buildpacks and Heroku as well as the 16 | Paketo Java buildpacks. Making this change will align the buildpack with the 17 | rest of the buildpack ecosystem. 18 | 1. There is native support to pass environment variables to the buildpack 19 | either on a per run basis or by configuration that can be checked into 20 | source control, in the form of `project.toml`. 21 | 22 | ## Implementation 23 | The proposed environment variables for CPython are as follow: 24 | 25 | #### BP_CPYTHON_VERSION 26 | ```shell 27 | $BP_CPYTHON_VERSION="3.7.10" 28 | ``` 29 | This will replace the following structure in `buildpack.yml`: 30 | ```yaml 31 | cpython: 32 | version: 3.7.10 33 | ``` 34 | 35 | ### Deprecation Strategy 36 | In order to facilitate a smooth transition from `buildpack.yml`, the buildpack 37 | should will support both configuration options with environment variables 38 | taking priority or `buildpack.yml` until the 1.0 release of the buildpack. The 39 | buildpack will detect whether or not the application has a `buildpack.yml` and 40 | print a warning message which will include links to documentation on how to 41 | upgrade and how to run builds with environment variable configuration. After 42 | 1.0, having a `buildpack.yml` will cause a detection failure and with a link to 43 | the same documentation. This behavior will only last until the next minor 44 | release of the buildpack after which point there will no longer be and error 45 | but `buildpack.yml` will not be supported. 46 | 47 | ## Source Material 48 | * [Google buildpack configuration](https://github.com/GoogleCloudPlatform/buildpacks#language-idiomatic-configuration-options) 49 | * [Paketo Java configuration](https://paketo.io/docs/buildpacks/language-family-buildpacks/java) 50 | * [Heroku configuration](https://github.com/heroku/java-buildpack#customizing) 51 | -------------------------------------------------------------------------------- /text/0059-standard-dependency-metadata-format.md: -------------------------------------------------------------------------------- 1 | # Standardized Paketo Dependency Metadata Format 2 | 3 | ## Summary 4 | 5 | This proposal suggests that the Paketo project should converge on a single 6 | dependency metadata format. 7 | 8 | ## Motivation 9 | 10 | There are several projects, such as the introduction of ARM or the removal of 11 | stacks, that are being discussed that would force Paketo to update the metadata 12 | for dependencies. It seems prudent that if we are going to have to do a large 13 | update to dependency metadata that it might also be a good time for us to 14 | converge as a project on the dependency metadata format that we should be using 15 | going forward. 16 | 17 | This could also be a good first step in converging on shared tooling. By having 18 | a shared dependency metadata format we would have a good common convergence 19 | point to begin building universal tooling for the Paketo project. 20 | 21 | ## Implementation 22 | 23 | The following is the proposed metadata format: 24 | 25 | ```toml 26 | [[metadata.dependencies]] 27 | checksum = "" 28 | id = "" 29 | uri = "" 30 | version = "dependency version" 31 | 32 | arch = "" #optional 33 | cpes = [ "" ] #optional 34 | eol-date = "" #optional 35 | name = "" #optional 36 | os = "" #optional 37 | purls = [ "" ] #optional 38 | source = "" #optional 39 | source-checksum = "" #optional 40 | strip-components = #optional 41 | 42 | [[metadata.dependencies.distros]] #optional 43 | name = "" 44 | version = "" #optional 45 | 46 | [[metadata.dependencies.licenses]] #optional 47 | type = "" 48 | uri = "" #optional 49 | ``` 50 | 51 | **Note:** Both the `distros` and `licenses` fields are optional, however if 52 | they are given then the non-optional components of them must be set. 53 | 54 | **Note:** If `os` or `arch` are not given it should be assumed that the 55 | dependency is OS or Architecture agnostic and is compatible to run on any given 56 | OS or Architecture. 57 | 58 | ## Prior Art 59 | - The layout of distributions is pulled from the [Buildpacks Spec](https://github.com/buildpacks/spec/blob/main/buildpack.md#buildpacktoml-toml). 60 | -------------------------------------------------------------------------------- /text/dependencies/rfcs/0002-dependency-server-purl.md: -------------------------------------------------------------------------------- 1 | # Add pURL Field to the Dependency Server Metadata 2 | 3 | ## Summary 4 | 5 | Add a field for pURLs into the dependency server schema. 6 | This RFC is an addendum to [RFC #0009](https://github.com/paketo-buildpacks/rfcs/blob/main/text/0009-dep-server.md) 7 | 8 | ## Motivation 9 | 10 | Currently, the dependency server offers a lot of valuable information about the 11 | files it hosts. However, it currently does not have the capacity to supply 12 | pURLs. This field should be added to the dependency server because pURLs are an 13 | industry standard package identifier that allow dependencies to be accurately 14 | identified by the end user. Package URLs are also a standard supported by the CycloneDX Bill of Materials format, and are [integrated with a number of other tools](https://github.com/package-url/purl-spec#users-adopters-and-links). Overall, package URLs can provide rich information beyond what's available via CPEs alone, making them a strong choice to include on our dependency metadata. 15 | 16 | ## Implementation 17 | 18 | The following field should be added to the dependency server output: 19 | 20 | * `purl`: a string which is a pURL for that dependency that conforms to the 21 | [pURL Specification](https://github.com/package-url/purl-spec). For 22 | consistency, we will be using the `generic` type because it allows to 23 | consistently generate the pURLs. Because we are using a `generic` type we 24 | will also be including the `source` and `source_sha256` as qualifiers on the 25 | pURL to give end users as much specific information as necessary. 26 | 27 | An example of the new output: 28 | ``` 29 | $ curl -sL https://api.deps.paketo.io/v1/dependency?name=go 30 | [ 31 | { 32 | "name": "go", 33 | "version": "1.15", 34 | "sha256": "29d4ae84b0cb970442becfe70ee76ce9df67341d15da81b370690fac18111e63", 35 | "uri": "https://deps.paketo.io/go/go_1.15_linux_x64_bionic_29d4ae84.tgz", 36 | "stacks": [ 37 | { 38 | "id": "io.buildpacks.stacks.bionic" 39 | }, 40 | { 41 | "id": "io.paketo.stacks.tiny", 42 | "mixins": ["some-required-mixin"] 43 | } 44 | ], 45 | "source": "https://dl.google.com/go/go1.15.src.tar.gz", 46 | "source_sha256": "69438f7ed4f532154ffaf878f3dfd83747e7a00b70b3556eddabf7aaee28ac3a", 47 | "deprecation_date": "", 48 | "licenses": ["BSD-3-Clause"], 49 | "purl": "pkg:generic/go@1.15?download_url=https://dl.google.com/go/go1.15.src.tar.gz&checksum=sha256:69438f7ed4f532154ffaf878f3dfd83747e7a00b70b3556eddabf7aaee28ac3a" 50 | } 51 | ] 52 | ``` 53 | -------------------------------------------------------------------------------- /text/0058-new-maintainer-group-process.md: -------------------------------------------------------------------------------- 1 | # Codify the Creation of New Maintainer Groups 2 | 3 | ## Summary 4 | 5 | This RFC is intended to define processes for the creation of new maintainer groups. 6 | 7 | ## Motivation 8 | 9 | Currently the creation of new maintainer groups is an ad hoc process that has to be hashed out every time a new group is requested. This means that intervention from the Steering Committee is often needed in situations where they should not need to weigh in. It also means that there is no standard record for the introduction of new groups meaning that the reasoning behind the formation of these new maintainer groups is lost. Codifying this process should make it easier to identify when new maintainer groups should be formed and make the process of doing so much easier. It should also give approval power to the stakeholders that will be directly affected by the introduction of new maintainer groups, namely the existing maintainer groups as opposed to the Steering Committee. 10 | 11 | ## Implementation 12 | 13 | The following are the scenarios in which a new maintainer group would be formed and the procedures for forming each group type. 14 | 15 | ### New Maintainer Group for New Repositories 16 | When proposing a new project that the proposer feels does not fall under the domain of an existing maintainer group they can suggest creating a new maintainer group. As part of the proposal, members of the initial maintainer group should be suggested or a request for volunteers should be open by the proposer of the new project. A new group must have sufficient membership to be considered. The group and the proposed initial set of members will then be reviewed and either approved or rejected by the Steering Committee. 17 | 18 | ### New Maintainer Group for Existing Repositories that are Maintained by One Existing Group 19 | When the repositories exist and are already under the control of an existing maintainer team but there is a desire to have a new maintainer group take over or co-maintain a portion of the existing repositories then the process will require a proposal RFC to create a new maintainer group. This RFC should outline the motivation for creating a new maintainer group and which repositories this new maintainer group would become responsible for maintaining. 20 | 21 | As part of the proposal, members of the initial maintainer group need to be recommended or a request for volunteers should be open and members located first. Groups will not be approved without sufficient membership. Then the steering committee and current maintainers will review the RFC and either approve or reject it. 22 | -------------------------------------------------------------------------------- /text/ruby/rake/0001-rake-task.md: -------------------------------------------------------------------------------- 1 | # Rake Task Execution 2 | 3 | ## Proposal 4 | 5 | Enable application developers to build images that execute `rake` tasks from a 6 | `Rakefile` at runtime. 7 | 8 | ## Motivation 9 | 10 | [`rake`](https://ruby.github.io/rake/) is a very common script/task execution 11 | framework. Ruby developers will commonly write `rake` tasks to run tests, 12 | execute database migrations, or build release artifacts. 13 | 14 | Developers can declare named tasks in a `Rakefile` which can be executed by 15 | running `rake `. Additionally, `rake` supports the concept of a 16 | "default" task that will be run when simply executing `rake` by itself. 17 | 18 | The buildpack should support both of these forms of execution, opting to 19 | support the "default" task as the primary launch process. 20 | 21 | ## Implementation 22 | 23 | Supporting the "default" case can be achieved by setting the launch process to 24 | `rake`. Therefore, when a developer executes their built image, the "default" 25 | task will be executed. 26 | 27 | Supporting the "specific" case, where an app developer wishes to execute a task 28 | that is not the default, the buildpack can leverage the [recent 29 | change](https://github.com/buildpacks/rfcs/blob/main/text/0045-launcher-arguments.md) 30 | in behavior of the launcher to support additional, user-provided arguments. 31 | 32 | For example, a user may build an application that contains the following `Rakefile`: 33 | 34 | ```ruby 35 | task default: %w[greet] 36 | 37 | desc "Prints a greeting" 38 | task :greet, [:name] do |t, args| 39 | args.with_defaults(:name => "World") 40 | puts "Hello, #{args.name}!" 41 | end 42 | ``` 43 | 44 | In this case, the built container image will have a launch command of `rake` 45 | which will enable some useful workflows for the given image. 46 | 47 | For example, the user can execute the "default" task: 48 | 49 | ``` 50 | $ docker run -it 51 | Hello, World! 52 | ``` 53 | 54 | Or list the tasks available in the `Rakefile`: 55 | 56 | ``` 57 | $ docker run -it --tasks 58 | rake greet[name] # Prints a greeting 59 | ``` 60 | 61 | Or execute a task by name: 62 | 63 | ``` 64 | $ docker run -it greet[Alice] 65 | Hello, Alice! 66 | ``` 67 | 68 | ### Bundler Support 69 | 70 | It is common for Ruby developers to use `bundler` for their applications, and 71 | we should ensure that the `rake` task executes with the gems specified in the 72 | `Gemfile`. Given this concern, the buildpack should modify the launch command 73 | to `bundle exec rake` if the source code contains a `Gemfile` and the `Gemfile` 74 | references `rake`. 75 | -------------------------------------------------------------------------------- /text/nodejs/0006-yarn-dependency.md: -------------------------------------------------------------------------------- 1 | # Providing a Yarn Dependency 2 | 3 | ## Proposal 4 | 5 | In order to enable other buildpacks to execute commands using the `yarn` CLI, 6 | this buildpack will make the `yarn` executable available on the `$PATH`. 7 | 8 | ## Motivation 9 | 10 | [`Yarn`](https://yarnpkg.com/) is a popular and common package manager for 11 | Javascript dependencies. Many Javascript developers will want to execute `yarn` 12 | commands as part of their `build` or `launch` process. Even more directly, 13 | there are already existing 14 | [buildpacks](https://github.com/paketo-buildpacks/yarn-install) that will want 15 | to execute `yarn` commands as part of their `build` process. 16 | 17 | In an effort to maintain modularity and simplicity, this buildpack will only 18 | install the executable and leave all other aspects of using `yarn` to other 19 | buildpacks. 20 | 21 | ## Implementation 22 | 23 | ### Detect Phase 24 | 25 | During detection, the buildpack will provide a `yarn` dependency in its 26 | buildplan. This will enable other buildpacks to require `yarn` be made 27 | available in the `build` and `launch` phases. 28 | 29 | Requiring the `yarn` dependency can be accomplished by writing a buildplan 30 | during the detect phase that includes the following requirement: 31 | 32 | ```toml 33 | [[requires]] 34 | name = "yarn" 35 | ``` 36 | 37 | ### Build Phase 38 | 39 | Given that `yarn` is required as part of the buildplan, the buildpack will 40 | create a layer and install the `yarn` executable into that layer, making it 41 | available to subsequent buildpacks or the launcher on the `$PATH` as part of 42 | the [Buildpack 43 | API](https://github.com/buildpacks/spec/blob/main/buildpack.md#layer-paths). 44 | 45 | ### Specifying dependency inclusion during lifecycle phases 46 | 47 | The buildpack will provide an API that allows other buildpacks to signal what 48 | phases the `yarn` executable should be made available in. This is accomplished 49 | by including extra metadata when requiring the `yarn` dependency in the detect 50 | phase. For example, to require that the `yarn` dependency be made available 51 | during both `build` and `launch`, specify a buildplan that looks like the 52 | following: 53 | 54 | ```toml 55 | [[requires]] 56 | name = "yarn" 57 | 58 | [requires.metadata] 59 | build = true 60 | launch = true 61 | ``` 62 | 63 | This will ensure that the layer that includes the `yarn` executable will be 64 | made available to subsequent buildpacks during the `build` phase. It also 65 | ensures that the layer will ultimately be included as part of the built 66 | application image, and thus available during the application `launch` phase. 67 | -------------------------------------------------------------------------------- /text/0000-add-ubi9-base-images.md: -------------------------------------------------------------------------------- 1 | # Create UBI9 base images 2 | 3 | ## Summary 4 | 5 | This RFC proposes creating a new repository that will develop, release, and maintain the UBI9 base images for use with buildpacks. 6 | 7 | ## Motivation 8 | 9 | Paketo Buildpacks organization ships UBI images based on RHEL 8 operating system and currently the default OS for base images offered by Red Hat is RHEL 9. By shipping UBI9 base images from Paketo Buildpacks organization, we allow users to build their applications with buildpacks on top of UBI9 base images and in addition, users can test their applications against the UBI9 base images for easier transition until UBI8 becomes EOL. 10 | 11 | ## Detailed Explanation 12 | 13 | Create a new repository named `paketo-buildpacks/ubi-9-base-images` and similar to how the (UBI8)[https://github.com/paketo-buildpacks/ubi8-base-stack] repository is structured and works, adjust it accordingly to produce the UBI9 base images. 14 | 15 | ## Rationale and Alternatives 16 | 17 | - We could release the UBI9 images under the UBI8 repository, but this would confuse the users and also does not follow the naming convention we use across the Paketo Buildpacks organization. 18 | - We could have ubi8 and ubi9 images under one repository, but in that case, there is a risk of hitting github limitations, e.g., the number of jobs each github workflow is allowed to run concurrently, and it will also trigger the UBI8 releases in case there is a UBI9 one available. 19 | 20 | ## Implementation 21 | 22 | 1. Create a new repository named `paketo-buildpacks/ubi-9-base-images` 23 | 24 | 1. The workflows of this repository should produce at least below container base images based on UBI9 images and also being able to extend the list in case future ubi-\*-extensions be available e.g. python, go, etc.: 25 | 26 | - `build-ubi9-base` 27 | - `run-ubi9-base` 28 | - `run-java-8-ubi9-base` 29 | - `run-java-11-ubi9-base` 30 | - `run-java-17-ubi9-base` 31 | - `run-java-21-ubi9-base` 32 | - `run-nodejs-16-ubi9-base` 33 | - `run-nodejs-18-ubi9-base` 34 | - `run-nodejs-20-ubi9-base` 35 | 36 | ## Prior Art 37 | 38 | The structure and implementation of the repository that will release, maintain, and develop UBI9 base images, will follow the structure/implementation of following stacks/images repositories: 39 | 40 | - https://github.com/paketo-buildpacks/ubi8-base-stack 41 | - https://github.com/paketo-buildpacks/jammy-base-stack 42 | - https://github.com/paketo-buildpacks/jammy-full-stack 43 | - https://github.com/paketo-buildpacks/jammy-static-stack 44 | - https://github.com/paketo-buildpacks/ubuntu-noble-base-images 45 | 46 | ## Unresolved Questions and Bikeshedding 47 | 48 | N/A 49 | -------------------------------------------------------------------------------- /text/ruby/0003-buildpack-yml-to-env-var.md: -------------------------------------------------------------------------------- 1 | # Buildpack.yml to Environment Variables 2 | 3 | ## Proposal 4 | 5 | Migrate to using environment variables to do all buildpack configuration and 6 | get rid of `buildpack.yml`. 7 | 8 | ## Motivation 9 | 10 | There are several reasons for making this switch. 11 | 1. There is already an [existing RFC](https://github.com/paketo-buildpacks/rfcs/blob/b885abe5fe0b8f64def4a79f0952b7050f3bee6f/accepted/0003-replace-buildpack-yml.md) that proposes moving away from `buildpack.yml` as a configuration tool. 12 | 1. Environment variables appears to be the standard for configuration in other 13 | buildpack ecosystems such as Google Buildpacks and Heroku as well as the 14 | Paketo Java buildpacks. Making this change will align the buildpack with the 15 | rest of the buildpack ecosystem. 16 | 1. There is native support to pass environment variables to the buildpack 17 | either on a per run basis or by configuration that can be checked into 18 | source control, in the form of `project.toml`. 19 | 20 | ## Implementation 21 | The proposed environment variables for Ruby are as follow: 22 | 23 | #### BP_MRI_VERSION 24 | ```shell 25 | $BP_MRI_VERSION="2.7.1" 26 | ``` 27 | This will replace the following structure in `buildpack.yml`: 28 | ```yaml 29 | mri: 30 | version: 2.7.1 31 | ``` 32 | 33 | #### BP_BUNDLER_VERSION 34 | ```shell 35 | $BP_BUNDLER_VERSION="2.1.4" 36 | ``` 37 | This will replace the following structure in `buildpack.yml`: 38 | ```yaml 39 | bundler: 40 | version: "2.1.4" 41 | ``` 42 | 43 | ### Deprecation Strategy 44 | In order to facilitate a smooth transition from `buildpack.yml`, the buildpack 45 | should will support both configuration options with environment variables 46 | taking priority or `buildpack.yml` until the 1.0 release of the buildpack. The 47 | buildpack will detect whether or not the application has a `buildpack.yml` and 48 | print a warning message which will include links to documentation on how to 49 | upgrade and how to run builds with environment variable configuration. After 50 | 1.0, having a `buildpack.yml` will cause a detection failure and with a link to 51 | the same documentation. This behavior will only last until the next minor 52 | release of the buildpack after which point there will no longer be and error 53 | but `buildpack.yml` will not be supported. 54 | 55 | ## Source Material 56 | * [Google buildpack configuration](https://github.com/GoogleCloudPlatform/buildpacks#language-idiomatic-configuration-options) 57 | * [Paketo Java configuration](https://paketo.io/docs/buildpacks/language-family-buildpacks/java) 58 | * [Heroku configuration](https://github.com/heroku/java-buildpack#customizing) 59 | -------------------------------------------------------------------------------- /text/stacks/0006-node-on-tiny.md: -------------------------------------------------------------------------------- 1 | # Add to Tiny Run Image to Enable Node Apps 2 | 3 | ## Summary 4 | 5 | At the moment, Node.js applications are not compatible with the tiny builder. Therefor the `nodejs` buildpack does not support the tiny stack. 6 | 7 | The tiny build image is already capable of building the Node.js application. 8 | 9 | The tiny run image is missing `libstdc++6`and `libgcc1`. 10 | 11 | ## Motivation 12 | 13 | To support running Node.js applications with the tiny builder. 14 | 15 | While not all Node.js applications could be supported by that, this could be a feasible approach: 16 | 17 | - `tiny`: Run Node.js applications **without** any native extenstions 18 | - `base`: Run Node.js applications **with** some native extensions 19 | - `full`: Run Node.js applications **with** many native extensions 20 | 21 | This should be desirable as some types of Node.js application would benefit of the reduced image size. 22 | 23 | ```bash 24 | apps/node-tiny latest 7546c8d45780 41 years ago 130MB 25 | apps/node-base latest 022cb9cea147 41 years ago 202MB 26 | apps/node-full latest 1324267830ec 41 years ago 803MB 27 | ``` 28 | 29 | Additionally image scans would find less CVEs for the application image which would make it easier to assess. On the other side, no additional CVEs for the run images (compared to `tiny`) were found by addind these libraries. 30 | 31 | | Image | Size Run Image (MB) | 32 | | --- | --- | 33 | | run-node-tiny | 19.2 | 34 | | paketobuildpacks/run:tiny | 17.4 | 35 | | paketobuildpacks/run:base | 86.7 | 36 | 37 | ## Detailed Explanation 38 | 39 | Install the [`libstdc++6`](https://packages.ubuntu.com/bionic/libstdc++6) and [`libgcc1`](https://packages.ubuntu.com/bionic/libgcc1) packages for the Ubuntu based tiny run image. It looks like this will add around 1.8 MB. 40 | 41 | The image scan results when writing this pr "only" showed one additional CVE (5.5) which would need to be assessed. 42 | 43 | ## Rationale and Alternatives 44 | 45 | - Node is written in C++, so it needs `libstdc++6`and `libgcc1` at runtime. 46 | - This would also allow other apps to use the tiny stack, e.g. Rust, C++, SAP JVM 47 | - This might be solved with the use of `extensions` which is currently discussed 48 | 49 | ## Implementation 50 | 51 | Install the `libstdc++6` and `libgcc1` packages for the Ubuntu based tiny run image. 52 | 53 | ## Prior Art 54 | 55 | None 56 | 57 | ## Unresolved Questions and Bikeshedding 58 | 59 | - Is it worth to influence other users of the stack? 60 | - Currently the `npm start` buildpack requires a `bash`, so any Node.js application using a start script would fail, but this can be changed in `npm start` 61 | -------------------------------------------------------------------------------- /text/0064-promote-ubi-builders.md: -------------------------------------------------------------------------------- 1 | # Promote ubi builders to paketo-buildpacks 2 | 3 | ## Summary 4 | 5 | Addition of ubi stacks was discussed and approved in 6 | [https://github.com/paketo-buildpacks/rfcs/blob/main/text/0056-ubi-based-stacks.md])https://github.com/paketo-buildpacks/rfcs/blob/main/text/0056-ubi-based-stacks.md). 7 | 8 | Initially repositories were added to to paketo-community to reflect that they were under early development. 9 | 10 | The ubi builders have been being built and published since August 2023, and they use the common Paketo workflows. 11 | 12 | No major updates are planned to the builders at this time. 13 | 14 | There are active maintainers for the builders and no significant issues open in the repo. 15 | 16 | The builders are ready to be promoted to paketo-buildpacks. 17 | 18 | ## Motivation 19 | 20 | Addition of ubi stacks was approved in 21 | [https://github.com/paketo-buildpacks/rfcs/blob/main/text/0056-ubi-based-stacks.md])https://github.com/paketo-buildpacks/rfcs/blob/main/text/0056-ubi-based-stacks.md). 22 | 23 | Promotion of builders to paketo-buildpacks from paketo-community is the next step towards completing that. 24 | 25 | ## Detailed Explanation 26 | 27 | * Rename https://github.com/paketo-community/builder-ubi-base/ to https://github.com/paketo-buildpacks/builder-ubi8-base/ 28 | * Rename https://github.com/paketo-community/builder-ubi-buildpackless-base/ to https://github.com/paketo-buildpacks/builder-ubi8-buildpackless-base/ 29 | * Rename all references to paketo-community/builder-ubi-base to paketo-buildpacks/builder-ubi8-base across the Paketo projects (references in integration testing) 30 | * Rename all references to paketo-community/builder-ubi-buildpackless-base to paketo-buildpacks/builder-ubi8-buildpackless-base across the Paketo projects (references in integration testing) 31 | 32 | The rename from ubi to ubi8 is to better reflect that the builder is for ubi8. Just like ubuntu there are different streams of ubi (8, 9, ...) and this is 33 | a good time to make the change. 34 | 35 | ## Rationale and Alternatives 36 | 37 | The builders are ready to be promoted to paketo-buildpacks there is no obvious reasons not to move to packeto-buildpacks. 38 | 39 | Alternative - leave the builder where is in paketo-community and define some additional milestones to be achived before it can be moved. 40 | 41 | ## Implementation 42 | 43 | See detailed explaination above in terms of the steps to implement. 44 | 45 | This will multple PRs to the repos that use the ubi builders for integration testing, but the main risk is missing updates during the transition. This is manageable and should not 46 | have a major impact. 47 | 48 | ## Prior Art 49 | 50 | 51 | ## Unresolved Questions and Bikeshedding 52 | 53 | -------------------------------------------------------------------------------- /text/java/0008-add-liberty-to-java-composite.md: -------------------------------------------------------------------------------- 1 | # Add open liberty buildpack to the Java buildpack 2 | 3 | ## Summary 4 | 5 | [RFC 0031](https://github.com/paketo-buildpacks/rfcs/blob/main/text/0031-liberty-buildpack.md) is currently being implemented. The liberty runtime is an application server similar to tomcat. This RFC proposes 6 | to add the open liberty buildpack to the Java buildpack as an alternate application server. 7 | 8 | ## Motivation 9 | 10 | There are a few motivations for this change: 11 | 12 | 1. The Open Liberty buildpack is not available out-of-the-box and requires manual steps to create a builder. 13 | 2. Including the open liberty buildpack in the composite java buildpack will make it easier for customers to find and use. 14 | 3. Other application servers can be added to the Java buildpack. 15 | 16 | ## Detailed Explanation 17 | 18 | Currently, the Java buildpack only contributes Tomcat. There is interest in the community for support for other Java application servers. However, the detection criteria for 19 | Tomcat and other servers will overlap since they can all deploy similar types of applications. If we can accommodate multiple applications servers then we can provide a more 20 | well-rounded java buildpack, reach more Java communities, generate more interest in Paketo and Cloud Native buildpacks, and ultimately make it easier for user to build images for Java applications. 21 | 22 | ## Rationale and Alternatives 23 | 24 | Alternatives: 25 | 26 | - Do nothing. Users of the Open Liberty buildpack will have to manually create a builder or manually specify the buildpack order, which is tedious. 27 | - Create a new composite buildpack (was in the origin liberty buildpack RFC), however, this has discovery problems (i.e. how do users find this since it's not in the Paketo builders). It also 28 | requires specifying a buildpack manually. 29 | 30 | ## Implementation 31 | 32 | In addition to the current criteria for each buildpack, the detect method will also validate itself against the value of `BP_JAVA_APP_SERVER` and contribute only if it matches. 33 | Tomcat will remain the default application server. 34 | 35 | | App server | tag | Buildpack | 36 | | ------------ | ------------ | --------------------------------------| 37 | | tomcat | tomcat | tomcat buildpack | 38 | | open liberty | openliberty | open liberty buildpack | 39 | | websphere liberty | websphereliberty | open liberty buildpack | 40 | 41 | Additional application servers can easily be added to the Java buildpack by implementing this RFC. 42 | 43 | ## Prior Art 44 | 45 | - None 46 | 47 | ## Unresolved Questions and Bikeshedding 48 | 49 | - None 50 | -------------------------------------------------------------------------------- /text/0020-blog.md: -------------------------------------------------------------------------------- 1 | # Self-host our blog via Hugo and GitHub Pages 2 | 3 | ## Summary 4 | 5 | Create our own self-hosted blog using [Hugo](https://gohugo.io/) and hosting 6 | via [GitHub Pages](https://pages.github.com/). 7 | 8 | ## Motivation 9 | 10 | The current blog uses Medium as its publishing platform. This has some obvious 11 | benefits, and also a few drawbacks. The benefits include a nicely themed blog 12 | layout and links to share posts on social networks. Some of the drawbacks 13 | include requiring that authors signup for a Medium account and possibly seeing 14 | our posts get placed behind a "login wall" when folks read too many posts on 15 | Medium. Hosting our own blog removes these drawbacks and makes the post 16 | creation process much more open. Additionally, it allows us full control over 17 | the look and feel of the blog site. 18 | 19 | ## Detailed Explanation 20 | 21 | Using Hugo, we can easily create a blogging platform that uses a post format 22 | that we are already familiar with, Markdown. We will get fine-grained control 23 | of the styling and features of the platform and can tailor it to our specific 24 | needs. Additionally, Hugo handles the vast majority of the complexity and makes 25 | hosting a blog like ours very simple. 26 | 27 | Here is an example of what our own blog could look like. As you can see, it 28 | more clearly aligns with the styling of the main website. 29 | 30 | ![Blog](/assets/blog-partial.png) 31 | 32 | Once the blog is created and made available as a repo in the 33 | [`paketo-buildpacks` GitHub org](https://github.com/paketo-buildpacks), we can 34 | start to host it on GitHub Pages. Hosting there is free and deployment is 35 | straightforward. It even allows us to use a custom domain like 36 | `blog.paketo.io`. We already use GitHub Pages to host the [main 37 | website](https://paketo.io) and our [dashboard](https://dashboard.paketo.io). 38 | 39 | We can also include some of the social media features that were present on 40 | Medium. It is relatively straight-forward to include "share buttons" for the 41 | major social networks that allow readers to share our posts. Here is what that 42 | might look like. 43 | 44 | ![Share sheet](/assets/blog-share-sheet.png) 45 | 46 | ## Rationale and Alternatives 47 | 48 | We could continue to use Medium, but its benefits over this proposal are quite 49 | marginal. 50 | 51 | ## Implementation 52 | 53 | 1. Create a new `blog` repository under the existing `Content` subteam. 54 | 1. Develop the look and feel of the blog using Hugo. 55 | 1. Copy over the existing posts currently hosted on Medium. 56 | 1. Deploy the blog using GitHub pages at `blog.paketo.io`. 57 | 1. Link to the new blog from the main Paketo website. 58 | 59 | ## Prior Art 60 | 61 | Existing self-hosted sites: 62 | 1. [paketo.io](https://paketo.io) 63 | 1. [dashboard.paketo.io](https://dashboard.paketo.io). 64 | -------------------------------------------------------------------------------- /text/go/go-mod-vendor/0001-vendor-rearchitecture.md: -------------------------------------------------------------------------------- 1 | # Go Mod Vendor Rearchitecture 2 | 3 | ## Proposal 4 | 5 | The main functionality provided by the `go-mod-vendor` buildpack will be to 6 | provide vendored dependencies using the `go mod vendor` command. More 7 | information about go modules can be found [here](https://golang.org/ref/mod). 8 | 9 | `go mod vendor` first looks for the `go.mod` file in the app root directory, 10 | which would be there as a result of running `go mod init` before the buildpack 11 | is run. This would be the app developer's responsibility if they want 12 | to use go modules. 13 | 14 | The `go.mod` file lives at the root of the app directory and contains the app 15 | dependencies, and gets updated by various go commands such as `go get`, `go 16 | mod tidy` or in this case `go mod vendor`. 17 | 18 | The [official documentation](https://golang.org/ref/mod#tmp_25) explains how go 19 | modules deal with vendoring: 20 | 21 | > The `go mod vendor` command constructs a directory named `vendor` in the main 22 | > module's root directory that contains copies of all packages needed to 23 | > support builds and tests of packages in the main module. 24 | 25 | > Once vendoring is enabled, packages are loaded from the `vendor` directory 26 | > instead of accessing the network or the module cache. 27 | 28 | ## Integration 29 | 30 | The proposed buildpack requires `go` and provides none. 31 | 32 | The former `go-mod` buildpack used to provide `go-mod`. 33 | 34 | ## Renaming 35 | 36 | The buildpack will be renamed to `go-mod-vendor` from `go-mod`. This will more 37 | clearly illustrate the specific function of the buildpack. 38 | 39 | The original `go-mod` buildpack contains logic that deals with binary building. 40 | Binary building logic will be removed from this buildpack and instead becomes a 41 | responsibility of the [`go-build`](https://github.com/paketo-buildpacks/go-build) buildpack. 42 | 43 | ## Implementation 44 | 45 | Detection will pass if a `go.mod` file is present in the app's source code. 46 | 47 | On detection, the buildpack will perform the following steps in the Build 48 | phase: 49 | 50 | - Retrieve or create a `mod-cache` layer, which will be a `cache` layer. 51 | - Set the `GOPATH` to point at the `mod-cache` layer. 52 | - Run `go mod vendor`. 53 | 54 | ## Motivation 55 | 56 | A big effort of the Paketo project is to move towards buildpacks that are 57 | responsible for a single function making the whole buildpack family structure 58 | more flexible, lightweight, and easier to maintain. With the proposed changes, 59 | the sole responsibility of this buildpack becomes managing application 60 | dependencies with go modules. As mentioned, the binary building logic gets 61 | offloaded to the `go-build` buildpack. 62 | 63 | ## Source Material (Optional) 64 | 65 | [Golang Documentation on Vendoring](https://golang.org/ref/mod#tmp_25) 66 | -------------------------------------------------------------------------------- /text/dotnet-core/0002-buildpack-yml-to-env-var.md: -------------------------------------------------------------------------------- 1 | # Buildpack.yml to Environment Variables 2 | 3 | ## Proposal 4 | 5 | Migrate to using environment variables to do all buildpack configuration and 6 | get rid of `buildpack.yml`. 7 | 8 | ## Motivation 9 | 10 | There are several reasons for making this switch. 11 | 1. There is already an existing RFC that proposes moving away from 12 | `buildpack.yml` as a configuration tool. 13 | 1. Environment variables appears to be the standard for configuration in other 14 | buildpack ecosystems such as Google Buildpacks and Heroku as well as the 15 | Paketo Java buildpacks. Making this change will align the buildpack with the 16 | rest of the buildpack ecosystem. 17 | 1. There is native support to pass environment variables to the buildpack 18 | either on a per run basis or by configuration that can be checked into 19 | source control, in the form of `project.toml`. 20 | 21 | ## Implementation 22 | The proposed environment variables for Dotnet are as follow: 23 | 24 | #### BP_DOTNET_FRAMEWORK_VERSION 25 | ```shell 26 | $BP_DOTNET_FRAMEWORK_VERSION="2.1.14" 27 | ``` 28 | This will replace the following structure in `buildpack.yml`: 29 | ```yaml 30 | dotnet-framework: 31 | version: "2.1.14" 32 | ``` 33 | 34 | #### BP_DOTNET_SDK_VERSION 35 | ```shell 36 | $BP_DOTNET_SDK_VERSION="2.1.804" 37 | ``` 38 | This will replace the following structure in `buildpack.yml`: 39 | ```yaml 40 | dotnet-sdk: 41 | version: "2.1.804" 42 | ``` 43 | 44 | #### BP_DOTNET_PROJECT_PATH 45 | ```shell 46 | $BP_DOTNET_PROJECT_PATH=./src/asp_web_app 47 | ``` 48 | This will replace the following structure in `buildpack.yml`: 49 | ```yaml 50 | dotnet-build: 51 | project-path: "src/asp_web_app" 52 | ``` 53 | 54 | ### Deprecation Strategy 55 | In order to facilitate a smooth transition from `buildpack.yml`, the buildpack 56 | should will support both configuration options with environment variables 57 | taking priority or `buildpack.yml` until the 1.0 release of the buildpack. The 58 | buildpack will detect whether or not the application has a `buildpack.yml` and 59 | print a warning message which will include links to documentation on how to 60 | upgrade and how to run builds with environment variable configuration. After 61 | 1.0, having a `buildpack.yml` will cause a detection failure and with a link to 62 | the same documentation. This behavior will only last until the next minor 63 | release of the buildpack after which point there will no longer be and error 64 | but `buildpack.yml` will not be supported. 65 | 66 | ## Source Material 67 | * [Google buildpack configuration](https://github.com/GoogleCloudPlatform/buildpacks#language-idiomatic-configuration-options) 68 | * [Paketo Java configuration](https://paketo.io/docs/buildpacks/language-family-buildpacks/java) 69 | * [Heroku configuration](https://github.com/heroku/java-buildpack#customizing) 70 | -------------------------------------------------------------------------------- /text/nodejs/0008-modular-yarn-install.md: -------------------------------------------------------------------------------- 1 | # Yarn Install Buildpack Modularization 2 | 3 | ## Proposal 4 | 5 | As part of the re-architecture of the Node.js metabuildpack outlined 6 | [here](https://github.com/paketo-buildpacks/nodejs/blob/main/rfcs/0001-buildpacks-architecture.md), 7 | the `yarn-install` buildpack should be changed to have the single responsibility of running the `yarn install` 8 | command, which will install dependencies to `node_modules`. 9 | 10 | Currently, the `yarn-install` buildpack is responsible for providing yarn on 11 | PATH, installing dependencies in the local node_modules folder, and sets a 12 | start command. With the work outlined in the re-architecture RFC linked above, 13 | the [`yarn` buildpack](https://github.com/paketo-buildpacks/yarn) and 14 | [`yarn-start` buildpack](https://github.com/paketo-buildpacks/yarn-start) have 15 | been created, and take care of providing yarn on PATH, and setting a start 16 | command, respectively. The last chunk of work in this group is to remove the 17 | extra functionality from `yarn-install`, so that each buildpack in the order 18 | grouping has a single, modular functionality. 19 | 20 | ## Motivation 21 | 22 | Moving toward this single-responsibility architecture has a few advantages: 23 | 24 | * It enables greater modularity within the Node.js language family. 25 | 26 | * It sets the foundation for interoperability between buildpacks across 27 | language families. 28 | 29 | * It provides clarity since the buildpacks are aptly named for their functionality. 30 | 31 | ## Integration 32 | 33 | The buildpack will provide `node_modules` and will require `node` and 34 | `yarn` during the build phase. 35 | 36 | ## Implementation (Optional) 37 | 38 | Detection will pass once there is both a `yarn.lock` and `package.json` file is present in the app's source 39 | code, assuming all other buildplan requirements have been met. 40 | 41 | If detection is passed, the buildpack will provide `node_modules` as a 42 | dependency. After the first build, the the sha256 of the `yarn.lock` file is 43 | cached, and yarn install will only run if the `yarn.lock` file has changed. 44 | 45 | The buildpack passes the `--frozen-lockfile` argument to every `yarn install` call, 46 | which will not update the `yarn.lock` file, and will fail if the `yarn.lock` file 47 | needs to be updated. So, developers must run `yarn install` locally in order to update 48 | their app's `yarn.lock` file. 49 | 50 | To use the buildpack in an offline environment 51 | the application must include an [`offline-mirror`](https://classic.yarnpkg.com/blog/2016/11/24/offline-mirror/) and [`.yarnrc`](https://classic.yarnpkg.com/en/docs/yarnrc/) file. The `yarn 52 | install` command will be run with the `--offline` flag if the offline mirror 53 | directory is present. The `offline-mirror` directory must be discoverable with the 54 | `yarn config get yarn-offline-mirror` command. 55 | -------------------------------------------------------------------------------- /text/python/0003-pip-rearchitecture.md: -------------------------------------------------------------------------------- 1 | # Pip Rearchitecture 2 | 3 | ## Proposal 4 | 5 | The existing pip buildpack should be rewritten and restructured to *only* 6 | provide the `pip` dependency. The `pip install` logic should be factored out 7 | into it's own buildpack. 8 | 9 | ## Motivation 10 | 11 | In keeping with the overarching [Python Buildpack Rearchitecture 12 | RFC](https://github.com/paketo-community/python/blob/main/rfcs/0001-restructure.md), 13 | the Pip Buildpack should perform one task, which is installing the `pip` 14 | dependency. This is part of the effort in Paketo Buildpacks to reduce the 15 | responsibilities of each buildpack to make them easier to understand 16 | and maintain. 17 | 18 | ## Implementation 19 | 20 | The implementation details are outlined in [this 21 | issue](https://github.com/paketo-community/pip/issues/82). Specifically, the 22 | new Pip Buildpack will always `detect` and will always `provide` `pip`. It 23 | will be the responsibility of a downstream buildpack (such as a future Pip 24 | Install buildpack) to `require` the `pip` dependency. 25 | 26 | The new `provides`/`requires` contract will initially be: 27 | 28 | * `pip` 29 | * provides: `pip` 30 | * requires: `cpython` OR {`python` + `requirements`} during `build` 31 | 32 | The {`python` + `requirements`} requirement is included for 33 | backwards-compatibility and will be removed towards the end of the full Python 34 | rearchitecture. 35 | 36 | 37 | The final `provides`/`requires` contract will be: 38 | 39 | * `pip` 40 | * provides: `pip` 41 | * requires: `cpython` during `build` 42 | 43 | ### Configuration 44 | 45 | Users may specify a Pip version through the `BP_PIP_VERSION` environment 46 | variable. This can be set explicitly at build time (e.g. `pack --env`) or through 47 | `project.toml`. 48 | 49 | ### Dependency Installation 50 | 51 | `Pip` installation involves a few steps: 52 | 53 | Download the pip dependency and untar it to a temporary directory (we refer to this 54 | as `` in this RFC). 55 | 56 | The buildpack runs `PYTHONUSERBASE= python -m pip 57 | install --user --find-links=` to install the requested version. Setting the 58 | `PYTHONUSERBASE` variable ensures that pip is installed to the newly created 59 | layer. 60 | 61 | The pip installation is then added to the `PATH` variable so that it may be 62 | invoked without the `python -m` prefix. 63 | 64 | The final step is prepending the `` onto the `PYTHONPATH` and 65 | exporting it as a shared environment variable for downstream buildpacks. This 66 | is necessary so Python looks for `pip` in the pip layer, instead of the default 67 | location. 68 | 69 | (EDIT: 03/17/2021 Added Configuration and Dependency Installation sections) 70 | (EDIT: 03/23/2021 The pip source is not a .tgz, update Dependency Installation section) 71 | -------------------------------------------------------------------------------- /text/ruby/bundle-install/0001-dev-test-gems-during-build.md: -------------------------------------------------------------------------------- 1 | # Provide development/test gems during build phase 2 | 3 | ## Proposal 4 | 5 | The buildpack should install and provide gems specified in the `development` 6 | and `test` groups in a layer that is made available to subsequent buildpacks 7 | during the build phase. The buildpack will also continue to exclude these 8 | `development` and `test` gems when providing a layer used for the `launch` 9 | phase. 10 | 11 | ## Motivation 12 | 13 | While we want to ensure we only install "production" dependencies when we build 14 | the application image, there are cases where buildpacks subsequent to the 15 | `bundle-install` buildpack will want to invoke code provided by gems that are 16 | including in the `development` or `test` groups. In its current implementation, 17 | these buildpacks would error as none of those dependencies are provided during 18 | the build phase. 19 | 20 | ## Implementation 21 | 22 | The buildpack will provide 2 different layers depending upon the metadata 23 | indicating what phases the gems will be required in. The implementation will 24 | follow these rules: 25 | 26 | 1. If the `gems` build plan entry is required during `build`, then the 27 | buildpack will create a layer with `build` and `cache` flags set to true. 28 | Into this layer it will install all gems, including those in the 29 | `development` and `test` groups. 30 | 31 | 2. If the `gems` build plan entry is required during `launch`, then the 32 | buildpack will create a layer with the `launch` flag set to true. Into this 33 | layer it will install only those gems that are not in the `development` or 34 | `test` groups. 35 | 36 | 3. If the `gems` build plan entry is required during both `build` and `launch`, 37 | then the buildpack will perform both of the steps outlined above. 38 | 39 | These layers will necessarily contain an overlapping set of gems. This is 40 | tolerable because the layers have different lifecycles, only being exposed to 41 | either the `build` or `launch` phases in a mutually exclusive relationship. 42 | 43 | The layers will also leverage build and launch environment variables to 44 | configure the location of the `BUNDLE_USER_CONFIG` environment variable to 45 | ensure the `bundle` CLI uses the correct gem set during each phase. 46 | 47 | ### Performance Implications 48 | 49 | In the worst case, when the `gems` build plan entry is required during both 50 | `build` and `launch`, the buildpack will need to install many of the same gems 51 | twice. To prevent this from being a huge performance penalty, the buildpack 52 | will perform the following steps: 53 | 54 | 1. Install all gems into the `build` layer. 55 | 2. Copy all gems from the `build` layer into the `launch` layer. 56 | 3. Execute the `launch` layer install process. This will remove those extra 57 | `development` and `test` gems as the process will execute `bundle clean`. 58 | -------------------------------------------------------------------------------- /text/utilities/0002-syft-buildpack.md: -------------------------------------------------------------------------------- 1 | # Syft Buildpack 2 | 3 | ## Summary 4 | 5 | Introduce a Syft buildpack. This buildpack will provide the [`syft` binary](https://github.com/anchore/syft) should any buildpacks want to use it. The `syft` CLI is a tool and library for generating a Software Bill of Materials from container images and filesystems. 6 | 7 | The Syft buildpack would be maintained by the existing [Utilities team](https://github.com/orgs/paketo-buildpacks/teams/utilities). It uses libpak & libcnb. 8 | 9 | ## Motivation 10 | 11 | It can be used by buildpacks to scan and generate both CycloneDX and SPDX listings of layers for compliance with [Buildpacks RFC #95](https://github.com/buildpacks/rfcs/blob/main/text/0095-sbom.md). 12 | 13 | ## Detailed Explanation 14 | 15 | 1. A Syft buildpack has been developed. It will be contributed to Paketo. 16 | 2. Other buildpacks wishing to compress binaries will opt-in by doing the following: 17 | 1. At detect time, require `syft`. 18 | 2. At build time after generating a binary, run `syft packages -q -o "dir:"` to scan a directory. Valid formats are `json`, `text`, `table`, `cyclonedx`, `spdx-tag-value`, and `spdx-json`. 19 | 20 | ## Rationale and Alternatives 21 | 22 | 1. `syft` could be added to the various build images. This is an easy option, but increases the build image size. It also does not allow a buildpack to guarantee that Syft is present, as some users have customized build images. 23 | 2. `syft` could be added into individual buildpacks, such as directly in the maven buildpack. Given that there are likely other buildpacks which can make use of Syft, this requires repetition of code across multiple buildpacks. 24 | 25 | ## Implementation 26 | 27 | The new Syft buildpack will participate all the following conditions are met 28 | 29 | * Another buildpack requires `syft` 30 | 31 | When conditions are met, the buildpack will do the following: 32 | 33 | * Contributes Syft to a layer marked `build` and `cache` with command on `$PATH` 34 | 35 | Buildpacks that wish to opt-in, simply need to indiate that they require `syft` at detection time. Then `syft` should be present on the path at build time and these buildpacks can run it. 36 | 37 | The Syft buildpack would need to be added to the order group for any language family that wishes to use `syft`. It needs to be added prior to the buildpack that is going to require `syft`, which would likely require it to be very early in the order group. For example, the maven buildpack will require Syft, so the Syft buildpack needs to be listed in the order groups prior to maven. If it's included and the exact order where it's included can be decided by each buildpack language family based on individual need. 38 | 39 | ## Prior Art 40 | 41 | * We include other utility tools in this manner, through a buildpack, like UPX and Watchexec 42 | 43 | ## Unresolved Questions and Bikeshedding 44 | 45 | None 46 | -------------------------------------------------------------------------------- /text/0052-graceful-stack-upgrades.md: -------------------------------------------------------------------------------- 1 | # Graceful Stack Upgrades 2 | 3 | ## Summary 4 | 5 | All Paketo Buildpacks should support graceful stack upgrades between the 6 | current Bionic and Jammy stacks. For most buildpacks, this should not require 7 | any changes, but for some buildpacks, layers created in previous builds that 8 | would normally be reused should be recreated if the stack ID changes. 9 | 10 | ## Motivation 11 | 12 | We have released support for the Jammy stack for a number of buildpacks at this 13 | point. It is an expectation of our users that they be able to gracefully 14 | upgrade the stack underlying their application image. However, some buildpacks 15 | may have produced layers that will no longer behave correctly once the stack 16 | has been modified. 17 | 18 | ## Detailed Explanation 19 | 20 | Buildpacks should consider adding tests that modify the underlying stack 21 | between subsequent builds to confirm that their buildpack handles this 22 | modification correctly. In most cases, this should require no changes to the 23 | buildpack beyond the addition of a new test to assert the modification works as 24 | expected. 25 | 26 | For some buildpacks, we will want to introduce code that tracks the stack ID 27 | between builds and recreates layers built with a stack ID that differs from the 28 | current `CNB_STACK_ID` value. 29 | 30 | Specifically, buildpacks that install dependencies they control will likely not 31 | need any modification given that their dependencies are mapped back to stacks 32 | through their metadata. Additionally, buildpacks that set a start command will 33 | also likely not need any modification as they rarely produce layers that would 34 | be tied to a specific stack. 35 | 36 | The types of buildpacks that will need to be investigated and fixed are likely 37 | to be those buildpacks that perform some sort of installation process, like 38 | `bundle-install` or `composer-install`. In these cases, the maintainers should 39 | investigate whether users are likely to see issues when swapping out stacks, 40 | and modify their buildpacks accordingly. 41 | 42 | To ensure that this graceful upgrade will work in all cases, buildpack authors 43 | should consider recreating layers when the previous stack ID was not recorded 44 | on the existing layer. This will result in a one-time penalty rebuild for 45 | applications that contain layers that didn't not record the previous stack ID. 46 | That cost seems like a reasonable tradeoff for correctly built images when the 47 | stack ID changes. 48 | 49 | ## Rationale and Alternatives 50 | 51 | Making the upgrade process as smooth as possible will ensure more users move to 52 | the new stacks. 53 | 54 | As an alternative, we could document that modifying the stack ID will require 55 | that users clear any cached layers from prior builds. 56 | 57 | ## Implementation 58 | 59 | Buildpacks will add integration tests that assert that they handle this stack 60 | ID modification correctly. 61 | -------------------------------------------------------------------------------- /text/java/0013-opentelemetry.md: -------------------------------------------------------------------------------- 1 | # OpenTelemetry Support 2 | 3 | ## Summary 4 | 5 | The [Paketo Java Buildpack](https://github.com/paketo-buildpacks/java) currently supports the APM tools Google Stackdriver, Azure Application Insights, and DataDog. This RFC proposes we add support for the open-source OpenTelemetry tool as well. 6 | 7 | ## Motivation 8 | 9 | OpenTelemetry has quickly became a standard for instrumenting, collecting, and exporting telemetry data. It's adopted and supported by industry leaders in the observability space. For Java applications, an OpenTelemetry Java Agent is available for instrumenting the code and exporting traces, metrics, and logs. 10 | 11 | ## Detailed Explanation 12 | 13 | This RFC proposes the following changes: 14 | 15 | - Create a new buildpack, `paketo-buildpacks/opentelemetry`. 16 | - The buildpack will install the OpenTelemetry Agent, which includes everything needed to instrument and export telemetry data. 17 | - The buildpack will adjust the JVM arguments to enable the OpenTelemetry Agent. 18 | - Users would configure the OpenTelemetry Agent using one of the following methods: 19 | - via the [standard environment variables](https://opentelemetry.io/docs/instrumentation/java/automatic/agent-config/#configuring-the-agent provided by the OpenTelemetry project itself. 20 | - via a configuration profile provided via a dedicated `opentelemetry` binding and that will be used to set the `OTEL_JAVAAGENT_CONFIGURATION_FILE` environment variable. 21 | - The initial target is for this buildpack to work with the JVM. However, support for other language families is possible in the future. 22 | 23 | ## Rationale and Alternatives 24 | 25 | The goal is to add easy support for using an open-source and industry-standard for handling telemetry in Java applications. Observability is a critical property of any cloud native application, and this buildpack would make it straightforward to instrument and collect telemetry from containerized workloads. Without the buildpack, it's still possible to include the agent manually, but the user experience would not be that great. 26 | 27 | ## Implementation 28 | 29 | 1. Create a new repo under `paketo-buildpacks/opentelemetry` 30 | 2. Set owner as Paketo Java subteam 31 | 3. Push a skeleton project using libcnb/libpak 32 | 4. Implement the buildpack based on the prototype [here](https://github.com/ThomasVitale/buildpacks-opentelemetry) (Apache 2 license) 33 | 5. Update dependencies 34 | 6. Add standard set of CI jobs 35 | 7. Document usage 36 | 8. Publish initial release 37 | 9. Submit sample application [here](https://github.com/paketo-buildpacks/samples/tree/main/java) 38 | 10. Update the Java documentation [here](https://github.com/paketo-buildpacks/paketo-website/blob/main/content/docs/howto/java.md#connect-to-an-apm) 39 | 40 | ## Prior Art 41 | 42 | - Azure Application Insights 43 | - Google Stack Driver 44 | - Datadog 45 | 46 | ## Unresolved Questions and Bikeshedding 47 | 48 | - None 49 | -------------------------------------------------------------------------------- /text/dotnet-core/0008-backwards-compatible-build-plan.md: -------------------------------------------------------------------------------- 1 | # Add Backwards Compatible Build Plan API in the .NET Core ASP.NET Runtime Buildpack 2 | 3 | ## Proposal 4 | 5 | We should make the build plan of the .NET Core ASP.NET Runtime buildpack 6 | backwards compatible so that is can fulfill the requirement of `dotnet-runtime` 7 | and `dotnet-aspnetcore` which are the requirements of the .NET Runtime and .NET 8 | ASP.NET buildpacks. This will allow us to archive those buildpacks and provide 9 | users that have buildpacks that rely on the existing build plan a grace period 10 | to upgrade their dependent buildpacks to the new build plan API. We will also 11 | be able to warn users and advise them to upgrade buildpacks that rely on the 12 | old build plan API. 13 | 14 | ## Motivation 15 | 16 | We would like to encourage users to move to the new .NET Core ASP.NET Runtime 17 | buildpack which superseded the functionality of the .NET Runtime and .NET 18 | ASP.NET buildpacks to be able to archive those buildpacks. However, we have not 19 | given users a more gradual upgrade path for potentially custom buildpacks that 20 | require the build plan API from the older buildpacks. With this change we will 21 | give users that more gradual upgrade path as well as making them aware that 22 | there has been a change to the underlying build plan API. 23 | 24 | Also by setting up this a backwards compatible API there should be no breaking 25 | change for users to switch to the .NET Core ASP.NET Runtime buildpack meaning 26 | that we can archive the the .NET Runtime and .NET ASP.NET buildpacks and remove 27 | them as a support burden. The current support burden for this buildpack is that 28 | it is requiring us to keep the `dep-server` running as it currently does all of 29 | the dependency updates for the old buildpacks so by archive the old buildpacks 30 | we should be able to remove the remaining `dep-server` workflows and begin the 31 | process of putting it in full time maintenance mode. 32 | 33 | ## Implementation 34 | 35 | The current build plan API is as follows: 36 | ```toml 37 | [[provides]] 38 | name = "dotnet-core-aspnet-runtime" 39 | ``` 40 | The following is a suggestion for a backwards compatible build plan API: 41 | ```toml 42 | [[provides]] 43 | name = "dotnet-core-aspnet-runtime" 44 | 45 | [[or]] 46 | 47 | [[or.provides]] 48 | name = "dotnet-runtime" 49 | 50 | [[or]] 51 | 52 | [[or.provides]] 53 | name = "dotnet-runtime" 54 | 55 | [[or.provides]] 56 | name = "dotnet-aspnetcore" 57 | ``` 58 | 59 | The backwards compatible API should be supported until the next major release 60 | and then we can remove it after that point is reached, hopefully giving people 61 | who use the old build plan API enough time to change their implementations. 62 | 63 | As part of this we should warn users using the older build plan during build 64 | that this API gateway is being removed and that they should transition their 65 | buildpacks to requiring `dotnet-core-aspnet-runtime` instead. 66 | -------------------------------------------------------------------------------- /text/0008-paketo-community.md: -------------------------------------------------------------------------------- 1 | # Paketo Community 2 | 3 | ## Summary 4 | 5 | The Paketo Community is a place where trusted community created buildpacks can be hosted. This would provide users a trusted place to search for buildpacks. 6 | 7 | ## Motivation 8 | 9 | There are two point why this community should exist. 10 | 11 | The Paketo Community will allow for the testing of new technologies or the development of buildpacks in an environment that is more flexible than that of the core Paketo. 12 | 13 | A trusted repository of community buildpacks will also allow for a trusted source of buildpacks that solve common yet still relatively niche problems that are not suitable to be added to core Paketo. 14 | 15 | ## Detailed Explanation 16 | 17 | A trusted project is a defined by the following: 18 | - The project must be actively maintained (i.e. issues and pull requests must be addressed regularly, approved pull requests must be merged or updated in a timely manner, etc.). 19 | - There must be visible automated testing for all repositories that are part of the project. 20 | - The project maintainers must conform to a set of best effort SLOs around patching critical CVEs when applicable to the project. 21 | 22 | This definition of trusted is meant to alleviate the following problems: 23 | 1. There must be a defined system in place to reap abandonware. 24 | 1. All repositories must meet some testing standard to be trusted in order to ensure that the projects support the latest Paketo technologies and platforms. 25 | 1. If a project maintainers are not making a best effort of patching out or updating vulnerable software then the project as a whole is untrustworthy. 26 | 27 | The maintainers must also be willing to sign the project over to the Cloud Foundry Foundation and conform to the licensing of the requirements laid out by the Cloud Foundry Foundation. 28 | 29 | ## Implementation 30 | 31 | For a new project to be added to the Paketo Community organization, it must conform to the standard of what it means to be a trusted project. Then the maintainers of the project may open a proposal for their project to be added to the Paketo Community organization. If this proposal gets sponsored by at least two maintainers of the Paketo project then the project may be merged into the Paketo Community organization. The responsibility of the maintainers that sponsored the project is to ensure that the project continues to meet the requirements of a trusted project and if it fails to meet that standard to remove it from the Paketo Community organization. 32 | 33 | ## Future Art 34 | 35 | Have a build process that is controlled by the Paketo project that will allow for the compilation to all Paketo and Paketo Community artifacts to ensure the security of the artifacts. 36 | 37 | ## Prior Art 38 | 39 | - [EPEL](https://fedoraproject.org/wiki/EPEL) and [PPA](https://launchpad.net/ubuntu/+ppas) 40 | - The [guarantee](https://fedoraproject.org/wiki/EPEL#Can_I_rely_on_these_packages.3F) the Red Hat gived for EPEL 41 | -------------------------------------------------------------------------------- /text/java/0006-oracle-jdk.md: -------------------------------------------------------------------------------- 1 | # Paketo Buildpacks Oracle Buildpack 2 | 3 | ## Summary 4 | 5 | A [Oracle Buildpack](https://github.com/eddumelendez/oracle) for supplying Oracle's distribution of OpenJDK has been created by [@eddumelendez][@eddumelendez]. It is built using common tooling (libpak and libjvm) used by the Paketo Java sub-team and should be adopted into the Paketo Buildpacks Github Org. 6 | 7 | ## Motivation 8 | 9 | We would like to move the Oracle Buildpack into the Paketo Buildpacks org so that the community can use it to build Java applications, in particular on Oracle Cloud Infrastructure. This will also give the buildpack maintainer the ability to leverage common Paketo tooling to keep the buildpack dependencies updated and release the buildpack. 10 | 11 | ## Detailed Explanation 12 | 13 | Oracle now has binary releases available under the [Oracle No-Fee Terms and Conditions License](https://java.com/freeuselicense). This is a different license than most of the other OpenJDK distributions available through buildpacks (the others utilize GPLv2 + classpath exception). 14 | 15 | This Oracle No-Fee Terms and Conditions license, in a nutshell, stipulates that it is OK to redistribute the binaries so long as these two conditions are met. 16 | 17 | 1. Do not modify the binaries that get redistributed with the buildpacks 18 | 2. Do not charge money for the binaries that get redistributed or for any software that redistributes them. 19 | 20 | No one writing or reviewing this RFC is a lawyer or qualified to provide legal advice, but it is believed that the buildpack to be contributed complies with these stipulations. 21 | 22 | Please be aware if you are consuming Paketo buildpacks and integrating them with other projects (commercial or OSS) & consult your own lawyer if needed. 23 | 24 | ## Rationale and Alternatives 25 | 26 | N/A 27 | 28 | ## Implementation 29 | 30 | The Oracle Buildpack will be moved into the `paketo-buildpacks` Github organization and added to the Java sub-team. Maintainenance for this buildpack will be provided by the Java subteam. 31 | 32 | The following changes will be made: 33 | 34 | - [Oracle Buildpack](https://github.com/eddumelendez/oracle) moved to Paketo Buildpacks org 35 | - Buildpack will have `paketo-buildpacks/oracle` ID 36 | - Buildpack will be published to `gcr.io/paketo-buildpacks/oracle` 37 | - Buildpack will have go module of `github.com/paketo-buildpacks/oracle` 38 | - An action will be added to [pipeline-builder](https://github.com/paketo-buildpacks/pipeline-builder/tree/main/actions) with the purpose of [checking for new versions of Oracle](https://www.oracle.com/java/technologies/jdk-script-friendly-urls/) 39 | 40 | ## Prior Art 41 | 42 | * [Microsoft OpenJDK Buildpack](https://github.com/paketo-buildpacks/rfcs/blob/main/text/java/0001-microsoft-jdk.md) 43 | * [Alibaba Dragonwell Buildpack](https://github.com/paketo-buildpacks/rfcs/blob/main/text/java/0002-alibaba-jdk.md) 44 | 45 | ## Unresolved Questions and Bikeshedding 46 | 47 | N/A 48 | -------------------------------------------------------------------------------- /text/go/go-build/0004-bp-go-build-ldflags.md: -------------------------------------------------------------------------------- 1 | # BP_GO_BUILD_LDFLAGS 2 | 3 | ## Proposal 4 | 5 | Add an environment variable `BP_GO_BUILD_LDFLAGS` which would allow users to 6 | set the value of `-ldflags` for their `go build` command. 7 | 8 | ## Motivation 9 | 10 | The `-ldflags` flag can have complicated values with multiple sets of internal 11 | quotation marks, an example of this complication can be seen in [this 12 | issue](https://github.com/paketo-buildpacks/go-build/issues/129). The goal of 13 | this environment variable is to remove one quotation level hopefully making it 14 | easier to express the `-ldflags` value with little to no escaping. 15 | 16 | ## Implementation 17 | 18 | If `BP_GO_BUILD_LDFLAGS` is set then `-ldflags` plus the value of the 19 | environment variable will be added to the `go build` command. 20 | 21 | The following is an example of a cumbersome `BP_GO_BUILD_FLAGS` caused by 22 | `-ldflags`: 23 | 24 | `BP_GO_BUILD_FLAGS="-ldflags=\"-extldflags '-f no-PIC -static'\" -tags=osusergo,netgo,embedfs"` 25 | 26 | If the same flag set were to be written using the proposed 27 | `BP_GO_BUILD_LDFLAGS` it would look like this: 28 | 29 | `BP_GO_BUILD_LDFLAGS="-extldflags '-f no-PIC -static'" BP_GO_BUILD_FLAGS="-tags=osusergo,netgo,embedfs"` 30 | 31 | ### Examples of Flag Merging 32 | 33 | 1. 34 | ``` 35 | Given BP_GO_BUILD_LDFLAGS="-extldflags '-f no-PIC -static'" 36 | Given BP_GO_BUILD_FLAGS is unset 37 | 38 | The resulting flags would be: 39 | -ldflags="-extldflags '-f no-PIC -static'" -buildmode pie . # the buildmode and target are defaults added by the buildpack 40 | ``` 41 | Summary: If no other flags are set by the user the `BP_GO_BUILD_LDFLAGS` will 42 | be treated as a flag set on its own and be included as part of the build 43 | command. 44 | 45 | 2. 46 | ``` 47 | Given BP_GO_BUILD_LDFLAGS="-extldflags '-f no-PIC -static'" 48 | Given BP_GO_BUILD_FLAGS="-tags=osusergo,netgo,embedfs" 49 | 50 | The resulting flags would be: 51 | -ldflags="-extldflags '-f no-PIC -static'" -tags=osusergo,netgo,embedfs -buildmode pie . 52 | ``` 53 | Summary: If `BP_GO_BUILD_LDFLAGS` and `BP_GO_BUILD_FLAGS` is set and 54 | `BP_GO_BUILD_FLAGS` does not include `-ldflags` then the `BP_GO_BUILD_LDFLAGS` 55 | will set `-ldflags` in the existing flag set. 56 | 57 | 3. 58 | ``` 59 | Given BP_GO_BUILD_LDFLAGS="-extldflags '-f no-PIC -static'" 60 | Given BP_GO_BUILD_FLAGS="-ldflags='some-ldflags' -tags=osusergo,netgo,embedfs" 61 | 62 | The resulting flags would be: 63 | -ldflags="-extldflags '-f no-PIC -static'" -tags=osusergo,netgo,embedfs -buildmode pie . 64 | ``` 65 | Summary: If `BP_GO_BUILD_LDFLAGS` and `BP_GO_BUILD_FLAGS` is set and 66 | `BP_GO_BUILD_FLAGS` does include `-ldflags` then the `BP_GO_BUILD_LDFLAGS` will 67 | overwrite `-ldflags` in the existing flag set. 68 | 69 | 70 | ## Unresolved Questions and Bikeshedding (Optional) 71 | 72 | * Is this necessary? Should we just document the escaping better? Should we do 73 | both? 74 | 75 | {{REMOVE THIS SECTION BEFORE RATIFICATION!}} 76 | -------------------------------------------------------------------------------- /text/utilities/0003-git-credential-configuration.md: -------------------------------------------------------------------------------- 1 | # Credential Configuration in the Git Buildpack 2 | 3 | ## Summary 4 | 5 | Add the ability to supply credentials to the Git buildpack that will be used by 6 | `git` in order to allow later buildpacks to perform operations that require 7 | `git` authentication. 8 | 9 | ## Motivation 10 | 11 | There are some operations, such as obtaining private language modules, that 12 | require `git` authentication during the build process. Currently there is no 13 | way of authenticating as a user to enable these workflows. Adding this 14 | functionality to the Git buildpack would open up a wider range of workflows 15 | than adding the functionality on an individual buildpack basis and make the 16 | ability to add credentials to the project universally. 17 | 18 | ## Implementation 19 | 20 | For security purposes, the credentials cannot be provided through an 21 | environment variable like most of our other buildpack configuration as this 22 | poses a risk of exposure by view the build process in some form of CI. Because 23 | of this restriction, an approach similar to the CA Certificates Buildpack will 24 | be used where the credentials will be provided in a mounted volume through a 25 | service binding. Those credentials will then be used to change the global `git` 26 | config for that container which will persist for the entirety of the build 27 | which the [CNB specification](https://github.com/buildpacks/spec/blob/main/buildpack.md#requirements) 28 | states must all happen in the same container for security purposes. 29 | 30 | The service binding structure will be as follows: 31 | - `type`: `git-credentials` 32 | - `context` (optional): The context is an optional pattern as defined by 33 | [`git`](https://git-scm.com/docs/gitcredentials#_credential_contexts). If a 34 | context is not provided then the credentials given in the binding will be the 35 | default credentials the `git` uses when authenticating. A given context can 36 | only be used once for any group of bindings, if a context is given by two 37 | separate bindings the build will fail. 38 | - `credentials`: The credentials file should have the following format to 39 | conform with the [`git` credential structure](https://git-scm.com/docs/git-credential#IOFMT). 40 | ``` 41 | username=some-username 42 | password=some-password/token 43 | ``` 44 | 45 | For every service binding the following `git` command will be run: 46 | ```shell 47 | git config --global credential.{{context}}.helper "!cat path/to/binding/credentials" 48 | ``` 49 | This command will add the following to the global `git` config: 50 | ```shell 51 | [credential "{{context}}"] 52 | helper = "!cat path/to/binding/credentials" 53 | ``` 54 | 55 | ## References 56 | 57 | - [Guide to Non-Interactive Git Authentication](https://coolaj86.com/articles/vanilla-devops-git-credentials-cheatsheet/) 58 | - [CA Certificates](https://github.com/paketo-buildpacks/ca-certificates) 59 | - [Custom Credential Helper](https://git-scm.com/docs/gitcredentials#_custom_helpers) 60 | -------------------------------------------------------------------------------- /text/ruby/0002-procfile.md: -------------------------------------------------------------------------------- 1 | # Procfile Support 2 | 3 | ## Proposal 4 | 5 | The [`Procfile` Buildpack](https://github.com/paketo-buildpacks/procfile/) 6 | should be added as an optional buildpack to the end of all order groups. 7 | 8 | ## Motivation 9 | 10 | The use of a `Procfile` to manage multiple application processes is common in 11 | the Ruby community. Several 12 | [services](https://devcenter.heroku.com/articles/procfile) and 13 | [tools](https://github.com/ddollar/foreman) already have existing support for 14 | this file format. Optionally supporting `Procfile` will allow users to 15 | configure their processes using tools they are already comfortable with. 16 | 17 | ## Implementation 18 | 19 | The `Procfile` buildpack will be added, optionally, as the last buildpack in 20 | each existing order group, as can be seen below: 21 | 22 | ```toml 23 | [[order]] 24 | 25 | [[order.group]] 26 | id = "paketo-community/mri" 27 | version = "0.0.139" 28 | 29 | [[order.group]] 30 | id = "paketo-community/bundler" 31 | version = "0.0.126" 32 | 33 | [[order.group]] 34 | id = "paketo-community/bundle-install" 35 | version = "0.0.31" 36 | 37 | [[order.group]] 38 | id = "paketo-community/puma" 39 | version = "0.0.22" 40 | 41 | [[order.group]] 42 | id = "paketo-buildpacks/procfile" 43 | version = "1.3.9" 44 | optional = true 45 | 46 | [[order]] 47 | 48 | [[order.group]] 49 | id = "paketo-community/mri" 50 | version = "0.0.139" 51 | 52 | [[order.group]] 53 | id = "paketo-community/bundler" 54 | version = "0.0.126" 55 | 56 | [[order.group]] 57 | id = "paketo-community/bundle-install" 58 | version = "0.0.31" 59 | 60 | [[order.group]] 61 | id = "paketo-community/thin" 62 | version = "0.0.19" 63 | 64 | [[order.group]] 65 | id = "paketo-buildpacks/procfile" 66 | version = "1.3.9" 67 | optional = true 68 | 69 | [[order]] 70 | 71 | [[order.group]] 72 | id = "paketo-community/mri" 73 | version = "0.0.139" 74 | 75 | [[order.group]] 76 | id = "paketo-community/bundler" 77 | version = "0.0.126" 78 | 79 | [[order.group]] 80 | id = "paketo-community/bundle-install" 81 | version = "0.0.31" 82 | 83 | [[order.group]] 84 | id = "paketo-community/unicorn" 85 | version = "0.0.17" 86 | 87 | [[order.group]] 88 | id = "paketo-buildpacks/procfile" 89 | version = "1.3.9" 90 | optional = true 91 | 92 | [[order]] 93 | 94 | [[order.group]] 95 | id = "paketo-community/mri" 96 | version = "0.0.139" 97 | 98 | [[order.group]] 99 | id = "paketo-community/bundler" 100 | version = "0.0.126" 101 | 102 | [[order.group]] 103 | id = "paketo-community/bundle-install" 104 | version = "0.0.31" 105 | 106 | [[order.group]] 107 | id = "paketo-community/rackup" 108 | version = "0.0.21" 109 | 110 | [[order.group]] 111 | id = "paketo-buildpacks/procfile" 112 | version = "1.3.9" 113 | optional = true 114 | ``` 115 | -------------------------------------------------------------------------------- /text/0044-disable-sbom.md: -------------------------------------------------------------------------------- 1 | # Provide Global Mechanism to Disable SBOM Generation 2 | 3 | ## Summary 4 | 5 | Users should have a mechanism to disable the generation of SBOM documents 6 | during the build process. 7 | 8 | ## Motivation 9 | 10 | The generation of the SBOM documents for an image can be very time-intensive in 11 | some cases. We have seen a doubling of build times for Node.js applications. 12 | Additionally, some users are not interested in taking advantage of the SBOM 13 | features of the buildpacks. 14 | 15 | ## Detailed Explanation 16 | 17 | If a user wishes to produce an image that does not contain SBOM documents, they 18 | can set the `BP_DISABLE_SBOM` environment variable to `true`. When unset, the 19 | value of this environment variable is assumed to be `false`. 20 | 21 | When `BP_DISABLE_SBOM` is set to `true`, buildpacks that allow SBOM to be 22 | omitted from their output should refrain from generating or attaching an SBOM 23 | in their outputs. This would apply to both new (Syft, CycloneDX, and SPDX 24 | formats) and old (label) SBOM outputs. 25 | 26 | Additionally, when this variable is set to `true` a buildpack should set an 27 | image label of `io.paketo.sbom.disabled` to `true`. This label interface would 28 | allow downstream consumers of the image to understand that SBOM generation had 29 | been explicitly disabled. 30 | 31 | ## Rationale and Alternatives 32 | 33 | Alternatively, we could not provide a mechanism to disable SBOM generation. 34 | This does not seem like a great option as the build-time penalty introduced by 35 | SBOM generation can be substantial. 36 | 37 | We could also not specify anything at the organizational level and let each 38 | buildpack subteam decide how they would like to handle this for their 39 | ecosystem. However, with regards to this particular feature, it doesn't seem 40 | like there would be a big need to have differing implementations of this flag 41 | for each ecosystem. It would mean in some polyglot build scenarios that users 42 | might need to specify that they'd like to disable SBOM generation in more than 43 | one way. We and users would likely benefit more from a standardized feature 44 | flag that worked uniformly across all buildpacks. 45 | 46 | ## Implementation 47 | 48 | Any buildpacks wishing to implement this feature will be required to honor the 49 | `BP_DISABLE_SBOM` environment variable. When set to `true` these buildpacks 50 | will neither generate their SBOM documents, nor attach them to any of their 51 | outputs. 52 | 53 | Additionally, when the variable is set, these buildpacks will include the image 54 | label `io.paketo.sbom.disabled` with a value of `true`. 55 | 56 | ## Other Notes and Details 57 | 58 | In the Buildpacks Spec v0.7/ Platform Spec v0.8, the restorer phase of the 59 | lifecycle [restores SBOMs from previous 60 | builds](https://github.com/buildpacks/spec/blob/buildpack/v0.7/platform.md#outputs-2). 61 | If a layer with an SBOM is restored by the lifecycle and the buildpack chooses 62 | to reuse that layer, it does not need to explicitly remove that restored SBOM 63 | from the layer. 64 | -------------------------------------------------------------------------------- /text/0022-core-deps-governance-restructure.md: -------------------------------------------------------------------------------- 1 | # Core-deps governance restructure proposal 2 | 3 | ## Summary 4 | 5 | Currently the core-dependencies team has no formal governance structure, which is at odds with the rest of the paketo org. In order to rectify this, we are proposing 6 | a formal governance structure that will designate specific maintainers and a contribution guide. Along with these changes will be permission restrictions following 7 | the paradigm of the rest of the paketo org. 8 | 9 | ## Motivation 10 | 11 | This will bring the repos that the core-dependencies team currently manage into line with the rest of the paketo org. Currently there is no formal contribution guide, 12 | no set roles between maintainers and contributors and the 'core-dependencies' team itself has no direct mapping to a concept within paketo. This will bring organization 13 | and formalization to these repositories. 14 | 15 | ## Detailed Explanation 16 | 17 | We plan on breaking the `core-dependencies` team into two separate teams: `stacks` and `dependencies`. The stacks team will handle all of the stacks related repos in the 18 | paketo org, and the dependencies team will handle all dependency related repos in the paketo org. Each of these teams will have 2 subteams: maintainers and contributors, and we will start 19 | disallowing direct pushes to main, instead forcing contributors to open PR's and RFC's for code-base changes. 20 | 21 | ## Rationale and Alternatives 22 | 23 | 1) One alternative would be to leave things how they are and have one team. This creates problems as our team grows, 24 | there's no clear delineation of permissions and thus everyone by default is a maintainer. Also currently without strong 25 | guards on pushing to main, this opens repositories to accidental damaging commits. 26 | 27 | 1) Another alternative would be to only have one new team that manages all of the repos, but with the same strict policy changes, 28 | including maintainer/contributor role implementation. 29 | 30 | 1) Another alternative would be to have potentially more than two teams. 31 | 32 | 33 | ## Implementation 34 | 35 | #### New Team Structure 36 | **Stacks Team** 37 | * Repos: stacks, base-release, full-release, tiny-release, stack-usns 38 | * Maintainers: Mark DeLillo, Kenneth DuMez, Marty Spiewak, paketo Bot Reviewer 39 | * Contributors: Brayan Henao, paketo Bot 40 | 41 | **Dependencies team** 42 | * Repos: dep-server 43 | * Maintainers: Mark DeLillo, Kenneth DuMez, Marty Spiewak, paketo Bot Reviewer 44 | * Contributors: Brayan Henao, paketo Bot 45 | 46 | #### Process Changes 47 | 48 | **Credentials** 49 | * Eventual goal: 50 | * Get rid of core-deps bot 51 | * Only use paketo/reviewer bot everywhere 52 | 53 | **Permissions:** forbid push to main, must PR/RFC in changes (applies to all managed repos) 54 | 55 | **Acceptance** 56 | * PRs: individual maintainers may accept 57 | * RFCs: requires supermajority of maintainers 58 | 59 | #### Finally 60 | Remove existing core-dependencies team 61 | 62 | ## Prior Art 63 | 64 | The proposed structure is heavily based on existing paketo governance. 65 | -------------------------------------------------------------------------------- /text/0062-promote-ubi-stack.md: -------------------------------------------------------------------------------- 1 | # Promote ubi stack to paketo-buildpacks 2 | 3 | ## Summary 4 | 5 | Addition of ubi stacks was discussed and approved in 6 | [https://github.com/paketo-buildpacks/rfcs/blob/main/text/0056-ubi-based-stacks.md])https://github.com/paketo-buildpacks/rfcs/blob/main/text/0056-ubi-based-stacks.md). 7 | 8 | Initially repositories were added to to paketo-community to reflect that they were under early development. 9 | 10 | The ubi stack has been being built and published since August 2023. Except where it implements 11 | advanced features like multi-arch it uses the common automation, and the team is working to integrate 12 | the advanced features back into the common versions of the automation flows. 13 | 14 | No major updates are planned to the stack, it already implements multi-arch and the only planned updates 15 | are to keep it up to date with newer releases of ubi 8. 16 | 17 | There are active maintainers for the stack and no significant issues open in the repo. 18 | 19 | The stack is ready to be promoted to paketo-buildpacks. 20 | 21 | ## Motivation 22 | 23 | Addition of ubi stacks was approved in 24 | [https://github.com/paketo-buildpacks/rfcs/blob/main/text/0056-ubi-based-stacks.md])https://github.com/paketo-buildpacks/rfcs/blob/main/text/0056-ubi-based-stacks.md). 25 | 26 | Promotion to paketo-buildpacks from paketo-community is the next step towards completing that. 27 | 28 | ## Detailed Explanation 29 | 30 | * Rename https://github.com/paketo-community/ubi-base-stack/ to https://github.com/paketo-buildpacks/ubi8-base-stack/ 31 | * Rename all references to paketo-community/ubi-base-stack to paketo-buildpacks/ubi8-base-stack across the Paketo projects (go project references and buildpack references) 32 | * Rename all references to paketocommunity/ubi-base-stack to paketobuildpacks/ubi8-base-stack across the Paketo projects (Docker containers references) 33 | 34 | The rename from ubi to ubi8 is to better reflect that the stack is for ubi8. Just like ubuntu there are different streams of ubi (8, 9, ...) and this is 35 | a good time to make the change. 36 | 37 | ## Rationale and Alternatives 38 | 39 | The stack is ready to be promoted to paketo-buildpacks there is no obvious reasons not to move to packeto-buildpacks. 40 | 41 | Alternative - leave the stack where is in paketo-community and define some additional milestones to be achived before it can be moved. 42 | 43 | ## Implementation 44 | 45 | * Rename https://github.com/paketo-community/ubi-base-stack/ to https://github.com/paketo-buildpacks/ubi8-base-stack/ 46 | * Rename all references to paketo-community/ubi-base-stack to paketo-buildpacks/ubi8-base-stack across the Paketo projects (go project references and buildpack references) 47 | * Rename all references to paketocommunity/ubi-base-stack to paketobuildpacks/ubi8-base-stack across the Paketo projects (Docker containers references) 48 | 49 | This will take PRs to the two ubi builder repositories, but the main risk is missing updates during the transition. This is manageable and should not 50 | have a major impact. 51 | 52 | ## Prior Art 53 | 54 | 55 | ## Unresolved Questions and Bikeshedding 56 | 57 | -------------------------------------------------------------------------------- /text/apm/0001-remove-nodejs.md: -------------------------------------------------------------------------------- 1 | # Remove Node.js Support from Application Monitoring Tools Buildpacks 2 | 3 | ## Summary 4 | 5 | This proposal is to remove the Node.js support from the Application Monitoring Tools buildpacks. 6 | 7 | ## Motivation 8 | 9 | When the APM Tools Buildpacks were contributed to Paketo, they came with Node.js support. On the surface, this sounds great. More support for different languages. This is not a bad thing, however, the way that these buildpacks implement support for Node.js is not consistent with what Node.js users expect or what the APM tool companies are recommending. Consequently, I do not believe anyone uses it. 10 | 11 | As evidence of that, I have intentionally not updated any of the Node.js tools for these buildpacks for close to half a year and no one has reached out about it or complained about them being out of date. Including the companies that create these tools. 12 | 13 | I have also reached out to some folks on the Node.js maintainers team to get opinions and have not found any supporting evidence of users or anyone that favors the approach of the Node.js implementation in the APM Tools buildpacks. 14 | 15 | ## Detailed Explanation 16 | 17 | The Node.js implementation in the APM Tools buildpacks has two flaws: 18 | 19 | 1. It downloads the Node.js tools in the buildpack. This is unexpected as a Node.js user. Node.js users expect things to be downloaded by the package manager (`npm`, `yarn`, etc...). 20 | 2. It then modifies the users code to inject and require the dependencies. Using `require` is outdated in many JavaScript/TypeScript projects and having a buildpack that modifies user code is a mistake. Buildpacks should not modify user code. 21 | 22 | ## Rationale and Alternatives 23 | 24 | Rationale is explained in the motivation section. 25 | 26 | I do not believe there are alternatives from the buildpacks perspective, because it is not expected for buildpacks to be injecting dependencies or modifying code. Node.js does not have external monitoring tools, like the JVM has agents, so there is not to my knowledge a way that buildpacks could do this without adding dependencies and modifying code. If anyone has other ideas, we could explore them though. 27 | 28 | ## Implementation 29 | 30 | Remove the Node.js support from the following buildpacks: 31 | 32 | - `paketo-buildpacks/appdynamics` 33 | - `paketo-buildpacks/elastic-apm` 34 | - `paketo-buildpacks/new-relic` 35 | - `paketo-buildpacks/google-stackdriver` 36 | - `paketo-buildpacks/datadog` 37 | - `paketo-buildpacks/azure-application-insights` 38 | 39 | The exception is `paketo-buildpacks/dynatrace`, for which we will not remove any support. Dynatrace support works differently, through a single agent that is injected outside of the Node.js runtime. Its implementation does not require adding Node.js dependencies or modifying code. 40 | 41 | After removing, we will post an announcement on the Paketo Buildpacks Blog. Users may continue using previous versions of the buildpack if they need support or fork from the commit, which we'll list in the buildpack, and continue maintaining on their own. 42 | 43 | ## Prior Art 44 | 45 | None 46 | 47 | ## Unresolved Questions and Bikeshedding 48 | 49 | None 50 | -------------------------------------------------------------------------------- /text/python/0005-pip-install-rearchitecture.md: -------------------------------------------------------------------------------- 1 | # Pip Install Architecture 2 | 3 | ## Proposal 4 | The Pip Install buildpack will use the package installer 5 | [pip](https://pypi.org/project/pip) to install dependencies from a 6 | `requirements.txt` file into a layer that will be managed by the buildpack. 7 | 8 | ## Motivation 9 | In keeping with the overarching [Python Buildpack Rearchitecture 10 | RFC](https://github.com/paketo-community/pip/blob/main/rfcs/0001-pip-rearchitecture.md), 11 | the Pip Install Buildpack should perform one task, which is installing from 12 | requirements files. This is part of the effort in Paketo Buildpacks to reduce 13 | the responsibilities of each buildpack to make them easier to understand and 14 | maintain. 15 | 16 | ## Implementation 17 | ### API 18 | - pip-install 19 | - `requires`: `cpython` and `pip` during build 20 | - `provides`: `site-packages` 21 | 22 | ### Detect 23 | The pip-install buildpack should only detect if there is a `requirements.txt` 24 | file at the root of the app. 25 | 26 | ### Build 27 | There will be two layers, `packages` layer and `cache` layer. 28 | The packages layer will contain the result of the pip install command. 29 | The cache layer will hold the pip [cache](https://pip.pypa.io/en/stable/reference/pip_install/#caching). 30 | 31 | During the build process, it will utilize the `pip` tool provided by the `pip` 32 | requirement (e.g. provided by the `paketo-community/pip` buildpack). 33 | 34 | The resulting build command run by the Pip Install buildpack will be: 35 | ```bash 36 | pip install 37 | --requirement # install from given requirements file 38 | --ignore-installed # ignores previously installed packages 39 | --exists-action=w # if path already exists, wipe before installation 40 | --cache-dir= # reuse pip cache 41 | --compile # compile python source files to bytecode 42 | --user # install to python user install directory set by PYTHONUSERBASE 43 | --disable-pip-version-check # ignore version check warning 44 | ``` 45 | Upgrade options are ignored if using `--ignore-installed` See [upgrade 46 | options](https://pip.pypa.io/en/stable/development/architecture/upgrade-options/). 47 | 48 | This should be run with the environment variable `PYTHONUSERBASE` set to the packages layer directory. 49 | 50 | If the app has a vendor directory at the root, the app will be considered vendored and the resulting build command will be: 51 | ```bash 52 | pip install 53 | --requirement 54 | --ignore-installed 55 | --exists-action=w 56 | --no-index # ignore package index, uses --find-links URLs 57 | --find-links=> # uses apps vendor directory 58 | --compile 59 | --user 60 | --disable-pip-version-check 61 | ``` 62 | 63 | #### Environment variables 64 | 65 | The buildpack should attach the environment variable `$PYTHONUSERBASE` to the 66 | `packages` layer, set its value to the layer's directory path, and make it 67 | available during both the build and launch phases. 68 | -------------------------------------------------------------------------------- /text/0005-ruby-promotion.md: -------------------------------------------------------------------------------- 1 | # Ruby Paketo Buildpack Promotion 2 | 3 | ## Summary 4 | 5 | A Ruby Buildpack has been created by contributors to the Paketo Project and currently resides in the [Paketo Community Github Org.](https://github.com/paketo-community/ruby). This RFC proposes the promotion of the Ruby Buildpack from a "Community" buildpack to an official Paketo Buildpack. 6 | 7 | ## Motivation 8 | 9 | The community Ruby Buildpack has reached an initial feature completion state and supports the most common Ruby app use cases. Ruby support in Paketo was intially requested by members of the CF community working on developing [CF for K8s](https://github.com/cloudfoundry/cf-for-k8s), and the resulting buildpack is actively used by components in CF for K8s as well as other community members. 10 | 11 | Ruby is one of the most popular programming languages so we'd like to promote it as an official Paketo project maintained Buildpack so that we can expose it to a much broader set of users (via the Paketo builders). 12 | 13 | ## Detailed Explanation 14 | The Ruby Buildpack is promoted to the `paketo-buildpacks` Github org. and considered an official language supported by the Paketo project. The Ruby Buildpack will be included in Paketo builders and promoted in website content. 15 | 16 | The buildpack currently provides MRI (Matz Ruby Interpreter) and Bundler as dependency and supports the most common web servers (Puma, Unicorn, Thin, Passenger, Rackup) as well as support for non-web server use cases such as Rake tasks. 17 | 18 | Upon promotion, future enhancements will be made from directly within the `paketo-buildpacks` org. 19 | 20 | ## Rationale and Alternatives 21 | 22 | N/A 23 | 24 | ## Implementation 25 | 26 | The following repos will be moved from the `paketo-community` to `paketo-buildpacks` Github Org: 27 | - [Language Family Ruby Buildpack](https://github.com/paketo-community/ruby) 28 | - [MRI Buildpack](https://github.com/paketo-community/mri) 29 | - [Bundler Buildpack](https://github.com/paketo-community/bundler) 30 | - [Bundle Install Buildpack](https://github.com/paketo-community/bundle-install) 31 | - [Puma Buildpack](https://github.com/paketo-community/puma/) 32 | - [Unicorn Buildpack](https://github.com/paketo-community/unicorn/) 33 | - [Thin Buildpack](https://github.com/paketo-community/thin/) 34 | - [Passenger Buildpack](https://github.com/paketo-community/passenger/) 35 | - [Rackup Buildpack](https://github.com/paketo-community/rackup/) 36 | - [Rake Buildpack](https://github.com/paketo-community/rake) 37 | 38 | **All** Ruby Buildpack IDs will be updated to `paketo-buildpacks/` 39 | 40 | **All** Ruby Buildpack artifacts will be shipped to `gcr.io/paketo-buildpacks/` 41 | 42 | The Ruby Buildpack will be added to Base & Full Paketo Builders as described in the [ordering RFC](https://github.com/paketo-buildpacks/builder/blob/main/rfcs/0001-buildpack-order.md) 43 | 44 | Sample apps for common Ruby app configurations will be added to the [Paketo samples repo](https://github.com/paketo-buildpacks/samples) 45 | 46 | Ruby logo will be added to the [Paketo website](https://github.com/paketo-buildpacks/samples) 47 | 48 | ## Prior Art 49 | 50 | N/A 51 | 52 | ## Unresolved Questions and Bikeshedding 53 | 54 | N/A -------------------------------------------------------------------------------- /text/0039-semantic-version-tags.md: -------------------------------------------------------------------------------- 1 | # Semantic Versioning in Tags for Buildpacks 2 | 3 | ## Summary 4 | 5 | To allow users to use the semantic versioning of buildpacks (see [rfc 0029](./0029-semantic-versioning.md)) in a convenient way, a buildpacks must have tags not only in the format `MAJOR.MINOR.PATCH`, but also `MAJOR.MINOR` and `MAJOR`. 6 | 7 | NOTE: Backporting security or bug fixes to older releases is not addressed by this RFC. 8 | 9 | ## Motivation 10 | 11 | Semantic versioning for buildpacks was introduced with [rfc 0029](./0029-semantic-versioning.md), but the buildpacks have only a tag for the complete version (`MAJOR.MINOR.PATCH`). So any user can either use this tag and get no updates at all or the user omits the tag and receives all updates including breaking changes automatically. 12 | 13 | With the use of the semantic versioning, it would be good to allow the user to specify which updates should be taken automatically. 14 | 15 | ## Detailed Explanation 16 | 17 | ### Major Version Update 18 | 19 | When a major version is updated `1.2.3` -> `2.0.0`: 20 | 21 | * Tag `2` should address the version `2.0.0` 22 | * Tag `2.0` should address the version `2.0.0` 23 | * Tag `2.0.0` should address the version `2.0.0` 24 | * Tag `latest` should address the version `2.0.0` 25 | 26 | This allows users to safeguard from incompatible changes, but still receive new features and security updates. 27 | 28 | ### Minor Version Update 29 | 30 | When a minor version is updated `1.2.3` -> `1.3.0` 31 | 32 | * Tag `1` should address the version `1.3.0` 33 | * Tag `1.3` should address the version `1.3.0` 34 | * Tag `1.3.0` should address the version `1.3.0` 35 | * Tag `latest` should address the version `1.3.0` (if v1 is still the latest one) 36 | 37 | This allows users to safeguard from incompatible changes and even minor changes, but still receive security updates. 38 | 39 | ### Patch Version Update 40 | 41 | When a patch version is updated `1.2.3` -> `1.2.4`: 42 | 43 | * Tag `1` should address the version `1.2.4` 44 | * Tag `1.2` should address the version `1.2.4` 45 | * Tag `1.2.4` should address the version `1.2.4` 46 | * Tag `latest` should address the version `1.2.4` (if v1.2 is still the latest one) 47 | 48 | This allows users to pin the version and to be sure that the image is the same. 49 | 50 | ## Rationale and Alternatives 51 | 52 | The only alternative is to keep everything as is. In such case we will miss the points described in the [Motivation](#motivation) 53 | 54 | ## Implementation 55 | 56 | The current workflows that push buildpack images to their registry locations already tag those images with the values `latest` and `MAJOR.MINOR.PATCH`. These workflows should be updated to also include `MAJOR.MINOR` and `MAJOR` tags. 57 | 58 | ## Prior Art 59 | 60 | This is a common pattern and often seen for docker images. A good example is the [Official Python Images](https://hub.docker.com/_/python?tab=tags). 61 | 62 | `python` is referring to the overall latest image available. 63 | `python:3` is pinning the major version to 3, but the latest minor and patch versions are used. 64 | `python:3.6` is pinning the major version to 3, the minor version to 6 but the latest patch version is used. 65 | `python:3.6.14` is pinning the exact version. 66 | -------------------------------------------------------------------------------- /text/java/0017-graalvm-jdk.md: -------------------------------------------------------------------------------- 1 | # Add support for Oracle GraalVM and update GraalVM CE buildpack 2 | 3 | ## Summary 4 | 5 | We will modify the [Oracle Buildpack](https://github.com/paketo-buildpacks/oracle) to include support for the new [Oracle GraalVM](https://www.oracle.com/java/graalvm/) distribution. 6 | 7 | In addition, the existing [`graalvm` buildpack](https://github.com/paketo-buildpacks/graalvm) will be clarified to indicate that it is the GraalVM Community buildpack. We cannot change its ID, but we will update the README and metadata to clarify this point. 8 | 9 | ## Motivation 10 | 11 | There are multiple motivations for this RFC: 12 | 13 | 1. Oracle has [introduced Oracle GraalVM](https://medium.com/graalvm/a-new-graalvm-release-and-new-free-license-4aab483692f5), a new and free GraalVM distribution that provides advanced features including G1 GC, SBOM, as well as performance and size optimizations. A new buildpack for Oracle GraalVM will, for example, allow Spring users to build more efficient and secure microservices. 14 | 2. The [`graalvm` buildpack](https://github.com/paketo-buildpacks/graalvm) only supports GraalVM Community Edition. Since this is only one of many GraalVM distributions (Community Edition, Oracle GraalVM, Liberica NIK, Mandrel, ...), it makes sense to adjust the name and the README of the buildpack, so that it is clear to users which distribution the buildpack includes (Community Edition). 15 | 3. The latest GraalVM release has dropped the GraalVM version in favor of the Java version, which may simplify the implementation and maintenance of the buildpack. 16 | 4. Due to the [alignment with OpenJDK](https://www.graalvm.org/2022/openjdk-announcement/), GraalVM is becoming more and more a standard JDK with Native Image support. The GraalVM Updater will be [deprecated in the GraalVM for JDK 21 release](https://github.com/oracle/graal/issues/6855) and removed in the future. 17 | 18 | 19 | ## Detailed Explanation 20 | 21 | This RFC proposes to address the items listed under Motivation as follows: 22 | 23 | 1. Update the [Oracle Buildpack](https://github.com/paketo-buildpacks/oracle) to support Oracle GraalVM. This will work just like what we have with the present Bellsoft Liberica buildpack, where the buildpack can provide a JVM and Native image tools. 24 | 2. Update the README & buildpack metadata for the existing GraalVM buildpack to indicate it is specifically for the GraalVM Community release. 25 | 26 | For more details, please see the [proof of concept](https://github.com/paketo-buildpacks/rfcs/pull/294). 27 | 28 | ## Rationale and Alternatives 29 | 30 | Alternatively, the existing `graalvm` buildpack could be reworked and extended with support for Oracle GraalVM. For this, we would need to offer an environment variable such as `$BP_DISTRIBUTION` for users to select a specific GraalVM distribution. However, that would be somewhat inconsistent with the `bellsoft-liberica` buildpack, which also includes a GraalVM distribution. Having separate buildpacks for different GraalVM distributions is also more consistent with the [Java buildpacks](0016-alternate-jvms-in-java-buildpack.md). 31 | 32 | ## Implementation 33 | 34 | See the Details section. The implementation plan as well as a proof of concept PR are documented there. 35 | -------------------------------------------------------------------------------- /text/0050-buildpack-rename.md: -------------------------------------------------------------------------------- 1 | # Rename Buildpacks 2 | 3 | ## Summary 4 | 5 | At present, the Paketo buildpacks follow a naming convention of `Paketo Buildpack`. This proposal is to change the naming convention and all existing buildpacks to follow the pattern `Paketo Buildpack for `. 6 | 7 | ## Motivation 8 | 9 | We are using various product and project names in the names of our buildpacks, but these names are trademarks of the project owners. While some of the relevant trademark owners are relaxed, others have usage guidelines that prohibit our naming approach. 10 | 11 | For example, the [Apache guidelines state](https://www.apache.org/foundation/marks/#products) `In general you may not use ASF trademarks in any software product branding. However in very specific situations you may use the Powered By naming form for software products.`. 12 | 13 | This is further complicated as you expand into support for commercial products which have non-OSS licenses. For example, the [Dynatrace guidelines](https://assets.dynatrace.com/global/legal/dynatrace-trademark-usage-guidelines-2021-08.pdf) state that their trademarks `must not be applied to the products or services of any other company.` However, the guidelines allow: `You may indicate the relationship of your products and services to Dynatrace products or services by using an accurate referential phrase in connection with your product or service, such as “for use with,” or “compatible with,” as long as your usage does not create the impression of any partnership with or endorsement by Dynatrace, and as long as your usage does not create the possibility of confusion as to the source of the product or service.`. 14 | 15 | The recommendation we have received is to use the naming convention `Paketo Buildpack for ` which more clearly separates our project work from the technology with which we are integrating. 16 | 17 | ## Detailed Explanation 18 | 19 | See [Motivation](#motivation) and [Implementation](#implementation) below. 20 | 21 | ## Rationale and Alternatives 22 | 23 | We could continue to use our existing naming schema. 24 | 25 | The information in this document was contributed to us by VMware's OSS/Legal team while going through their process to [contribute APM Tooling buildpacks](https://github.com/paketo-buildpacks/rfcs/pull/222). It does not represent a mandate or requirement to change. 26 | 27 | ## Implementation 28 | 29 | The following actions will need to be taken: 30 | 31 | 1. For each buildpack, update README.md & buildpack.toml changing the buildpack name. This plan does not change buildpack IDs, Github repository names or image registry coordinates. Because buildpacks only use the name for astetic purposes, we do not anticipate this change to break users. 32 | 33 | 2. For the Paketo Website, we'll need to update documentation that references buildpack names. 34 | 35 | 3. For the Paketo Samples, we'll need to update documentation that references buildpack names. 36 | 37 | 4. Some buildpacks may have unit/integration tests which reference the names of buildpacks. For example, if a test is attempting confirm a buildpack has run, it may look for the buildpack name in the build logs to confirm. 38 | 39 | ## Prior Art 40 | 41 | - None 42 | 43 | ## Unresolved Questions and Bikeshedding 44 | 45 | - None 46 | -------------------------------------------------------------------------------- /text/go/go-build/0003-buildpack-yml-to-env-var.md: -------------------------------------------------------------------------------- 1 | # Buildpack.yml to Environment Variables 2 | 3 | ## Proposal 4 | 5 | Migrate to using environment variables to do all buildpack configuration and 6 | get rid of `buildpack.yml`. 7 | 8 | ## Motivation 9 | 10 | There are several reasons for making this switch. 11 | 1. There is already an existing RFC that proposes moving away from 12 | `buildpack.yml` as a configuration tool. 13 | 1. Environment variables appears to be the standard for configuration in other 14 | buildpack ecosystems such as Google Buildpacks and Heroku as well as the 15 | Paketo Java buildpacks. Making this change will align the buildpack with the 16 | rest of the buildpack ecosystem. 17 | 1. There is native support to pass environment variables to the buildpack 18 | either on a per run basis or by configuration that can be checked into 19 | source control, in the form of `project.toml`. 20 | 21 | ## Implementation 22 | 23 | The proposed environment variables for Go Build are as follow: 24 | 25 | #### BP_GO_BUILD_FLAGS 26 | 27 | ```shell 28 | $BP_GO_BUILD_FLAGS='-buildmode=default -tags=paketo -ldflags="-X main.variable=some-value"' 29 | ``` 30 | 31 | Note: This will be parsed using this [shellwords 32 | library](https://github.com/mattn/go-shellwords). This is being done because 33 | GOFLAGS does not support flags that have spaces in them. 34 | 35 | This will replace the following structure in `buildpack.yml`: 36 | 37 | ```yaml 38 | go: 39 | build: 40 | flags: 41 | - -buildmode=default 42 | - -tags=paketo 43 | - -ldflags="-X main.variable=some-value" 44 | ``` 45 | 46 | #### BP_GO_BUILD_IMPORT_PATH 47 | 48 | ```shell 49 | $BP_GO_BUILD_IMPORT_PATH=example.com/some-app 50 | ``` 51 | 52 | This will replace the following structure in `buildpack.yml`: 53 | 54 | ```yaml 55 | go: 56 | build: 57 | import-path: example.com/some-app 58 | ``` 59 | 60 | #### BP_GO_TARGETS 61 | 62 | ```shell 63 | $BP_GO_TARGETS=./cmd/web-server:./cmd/debug-server 64 | ``` 65 | 66 | This will replace the following structure in `buildpack.yml`: 67 | 68 | ```yaml 69 | go: 70 | targets: 71 | - ./cmd/web-server 72 | - ./cmd/debug-server 73 | ``` 74 | 75 | ### Deprecation Strategy 76 | In order to facilitate a smooth transition from `buildpack.yml`, the buildpack 77 | will support both configuration options with environment variables taking 78 | priority or `buildpack.yml` until the 1.0 release of the buildpack. The 79 | buildpack will detect whether or not the application has a `buildpack.yml` and 80 | print a warning message which will include links to documentation on how to 81 | upgrade and how to run builds with environment variable configuration. After 82 | 1.0, having a `buildpack.yml` will cause a detection failure and with a link to 83 | the same documentation. This behavior will only last until the next minor 84 | release of the buildpack after which point there will no longer be and error 85 | but `buildpack.yml` will not be supported. 86 | 87 | ## Source Material 88 | * [Google buildpack configuration](https://github.com/GoogleCloudPlatform/buildpacks#language-idiomatic-configuration-options) 89 | * [Paketo Java configuration](https://paketo.io/docs/buildpacks/language-family-buildpacks/java) 90 | * [Heroku configuration](https://github.com/heroku/java-buildpack#customizing) 91 | -------------------------------------------------------------------------------- /text/0006-web-servers.md: -------------------------------------------------------------------------------- 1 | # Web Servers Buildpack Subteam 2 | 3 | ## Summary 4 | 5 | A new "Web Servers" buildpack subteam should be established to maintain and 6 | distribute the existing set of related buildpacks that interact in the web 7 | server space. 8 | 9 | ## Motivation 10 | 11 | The existing NGINX, Apache HTTP Server, and Staticfile buildpacks have a common 12 | set of concerns within the web server space. However, the buildpacks are 13 | currently maintained either through tangentially-related subteams (PHP) or not 14 | at all through a subteam (Staticfile). Giving these buildpacks a common subteam 15 | that can hear community concerns and maintain the buildpacks more effectively 16 | while reducing the scope of responsibilities for the PHP subteam would be a 17 | positive benefit for the core development team and the community. 18 | 19 | ## Detailed Explanation 20 | 21 | The Web Server subteam will take over maintenance of the existing 22 | [NGINX](https://github.com/paketo-buildpacks/nginx) and [Apache HTTP 23 | Server](https://github.com/paketo-buildpacks/httpd) buildpacks, as well as the 24 | [Staticfile](https://github.com/paketo-community/staticfile) buildpack. 25 | 26 | Additionally, this subteam will create a new language-family buildpack that 27 | will package these buildpacks together in collaboration. This buildpack should 28 | start out as a new addition to the [Paketo Community 29 | organization](https://github.com/paketo-community). 30 | 31 | ## Rationale and Alternatives 32 | 33 | We could choose to maintain the status quo. 34 | 35 | ## Implementation 36 | 37 | New maintainers should be elected for this subteam. These maintainers can then 38 | elect contributors to help support the responsibilities of the subteam. 39 | 40 | A new GitHub team for Web Servers should be established. Within that team, both 41 | maintainers and contributors teams should be created with those chosen 42 | individuals included in their corresponding team. This GitHub team will also 43 | need to be created in the Paketo Community organization as the repositories 44 | this subteam maintains will span both organizations. 45 | 46 | The maintainer/contibutor ownerships for the NGINX, Apache HTTP Server, and 47 | Staticfile buildpack repositories should be transfered to this subteam. 48 | Additionally, the CODEOWNERS for those repositories should be transferred. 49 | 50 | A new buildpack repository should be created in the Paketo Community 51 | organization to the Web Server language-family buildpack. This buildpack should 52 | include a `buildpack.toml` that declares an order grouping like the following: 53 | 54 | ```toml 55 | [[order]] 56 | 57 | [[order.group]] 58 | id = "paketo-buildpacks/nginx" 59 | version = "1.2.3" 60 | 61 | [[order.group]] 62 | id = "paketo-community/staticfile" 63 | version = "1.2.3" 64 | 65 | [[order]] 66 | 67 | [[order.group]] 68 | id = "paketo-buildpacks/nginx" 69 | version = "1.2.3" 70 | 71 | [[order]] 72 | 73 | [[order.group]] 74 | id = "paketo-buildpacks/httpd" 75 | version = "1.2.3" 76 | ``` 77 | 78 | The language-family buildpack should produce releases and make itself available 79 | on the `gcr.io/paketo-community` image registry. 80 | 81 | ## Unresolved Questions and Bikeshedding 82 | 83 | - How should the maintainers be elected? 84 | 85 | {{REMOVE THIS SECTION BEFORE RATIFICATION!}} 86 | -------------------------------------------------------------------------------- /text/0001-repo-migration.md: -------------------------------------------------------------------------------- 1 | # Paketo Repo Migration Proposal 2 | 3 | ## Summary 4 | Below we propose what repositories we will migrate into the paketo-buildpacks org. 5 | 6 | ## Implementation 7 | 8 | #### NodeJS CNB (language family and implementation CNBs) 9 | - nodejs (metabuildpack) 10 | - node-engine 11 | - yarn-install 12 | - npm 13 | 14 | #### Go CNB (language family and implementation CNBs) 15 | - go (metabuildpack) 16 | - go-compiler 17 | - go-mod 18 | - dep 19 | 20 | #### Dotnet Core CNB (language family and implementation CNBs) 21 | - dotnet-core (metabuildpack) 22 | - dotnet-core-runtime 23 | - dotnet-core-aspnet 24 | - dotnet-core-sdk 25 | - dotnet-core-build 26 | - dotnet-core-conf 27 | - icu 28 | 29 | #### PHP CNB (language family and implementation CNBs) 30 | 31 | - php (metabuildpack) 32 | - php-web 33 | - php-composer 34 | - php-dist 35 | 36 | #### Httpd CNB (language family and implementation CNBs) 37 | 38 | - httpd 39 | 40 | #### Nginx CNB (language family and implementation CNBs) 41 | 42 | - nginx 43 | 44 | #### Java CNB (language family and implementation CNBs) 45 | 46 | - adopt-openjdk 47 | - amazon-corretto 48 | - apache-tomcat 49 | - azul-zulu 50 | - azure-application-insights (Java and NodeJS - - Implementations) 51 | - bellsoft-liberica 52 | - build-system 53 | - debug 54 | - dist-zip 55 | - eclipse-openj9 56 | - encrypt-at-rest 57 | - executable-jar 58 | - google-stackdriver (Java and NodeJS Implementations) 59 | - jmx 60 | - procfile 61 | - sap-machine 62 | - spring-boot 63 | 64 | #### Libraries 65 | 66 | - packit 67 | - libpak 68 | - libjvm 69 | 70 | #### Other 71 | 72 | - builder formerly (cnb-builder) 73 | - stacks 74 | - build-common 75 | - pipeline-builder 76 | - occam 77 | - samples 78 | 79 | #### Libraries to be left out 80 | 81 | - Python-cnb and all Python implementation CNBs 82 | - Ruby family CNBs 83 | - libbuildpack or libcfbuildpack 84 | - no shim-related code (cnb2cf, etc..) 85 | 86 | 87 | ### Buildpack Repo/ID/Name proposal: 88 | We propose the following naming conventions for repositories, buildpack id's and registry path. 89 | 90 | ### Repo: 91 | 92 | Buildpack implementation repositories should be descriptively named and exclude any reference to "buildpack" or "Cloud Native Buildpack". 93 | 94 | Ex: 95 | 96 | github.com/paketo-buildpacks/node-engine 97 | 98 | ### IDs: 99 | The ID's of each buildpack ( in `buildpack.toml` ) should conform to the following. 100 | 101 | paketo-buildpacks/ 102 | 103 | Here the `` should be equivalent to the repository name in paketo-buildpacks, and follow the same conventions. 104 | 105 | 106 | ### Registry: 107 | 108 | Buildpacks in the paketo org will also have a compiled and usable artifact available on GCR at the following paths: 109 | 110 | gcr.io/ 111 | 112 | So for the `node-engine` buildpack this would be 113 | 114 | gcr.io/paketo-buildpacks/node-engine 115 | 116 | 117 | ### Stack Repo/ID/Name proposal: 118 | Below is a plan for how the component pieces of stacks & builders should be named. 119 | 120 | #### Builders 121 | gcr.io/paketo-buildpacks/builder: 122 | 123 | #### Build Images 124 | gcr.io/paketo-buildpacks/build: 125 | 126 | #### Run Images 127 | gcr.io/paketo-buildpacks/run: 128 | 129 | --------------------------------------------------------------------------------