Below we propose what repositories we will migrate into the paketo-buildpacks org.
- nodejs (metabuildpack)
- node-engine
- yarn-install
- npm
- go (metabuildpack)
- go-compiler
- go-mod
- dep
- dotnet-core (metabuildpack)
- dotnet-core-runtime
- dotnet-core-aspnet
- dotnet-core-sdk
- dotnet-core-build
- dotnet-core-conf
- icu
- php (metabuildpack)
- php-web
- php-composer
- php-dist
- httpd
- nginx
- adopt-openjdk
- amazon-corretto
- apache-tomcat
- azul-zulu
- azure-application-insights (Java and NodeJS - - Implementations)
- bellsoft-liberica
- build-system
- debug
- dist-zip
- eclipse-openj9
- encrypt-at-rest
- executable-jar
- google-stackdriver (Java and NodeJS Implementations)
- jmx
- procfile
- sap-machine
- spring-boot
- packit
- libpak
- libjvm
- builder formerly (cnb-builder)
- stacks
- build-common
- pipeline-builder
- occam
- samples
- Python-cnb and all Python implementation CNBs
- Ruby family CNBs
- libbuildpack or libcfbuildpack
- no shim-related code (cnb2cf, etc..)
We propose the following naming conventions for repositories, buildpack id's and registry path.
Buildpack implementation repositories should be descriptively named and exclude any reference to "buildpack" or "Cloud Native Buildpack".
Ex:
github.com/paketo-buildpacks/node-engine
The ID's of each buildpack ( in buildpack.toml
) should conform to the following.
paketo-buildpacks/<name-without-cnb-suffix>
Here the <name>
should be equivalent to the repository name in paketo-buildpacks, and follow the same conventions.
Buildpacks in the paketo org will also have a compiled and usable artifact available on GCR at the following paths:
gcr.io/<id>
So for the node-engine
buildpack this would be
gcr.io/paketo-buildpacks/node-engine
Below is a plan for how the component pieces of stacks & builders should be named.
gcr.io/paketo-buildpacks/builder:<builder-name>
gcr.io/paketo-buildpacks/build:<build-image-name>
gcr.io/paketo-buildpacks/run:<run-image-name>