paketo-buildpacks / procfile

A buildpack for translating a Procfile into Process Types

gcr.io/paketo-buildpacks/procfile

The Procfile Buildpack is a Cloud Native Buildpack that turns the contents of a Procfile into process types.

Behavior

This buildpack will participate if one or all of the following conditions are met:

• The application contains a Procfile
• A Binding exists with type Procfile and secret containing a Procfile
• The BP_PROCFILE_DEFAULT_PROCESS environment variable is set to a non-empty value

The buildpack will do the following:

• When BP_PROCFILE_DEFAULT_PROCESS is set, it will contribute the web process type to the image.
• Contribute the process types from one or both Procfile files to the image.
  • If process types are identified from both Binding and file, the contents are merged into a single Procfile. Commands from the Binding take precedence if there are duplicate types.
  • If process types are identified from environment and Binding or file, the contents are merged into a single Procfile. Commands from Binding or file take precedence if there are duplicate types, with Binding taking precedence over file.
  • If the application's stack is io.paketo.stacks.tiny the contents of the Procfile must be single command with zero or more space delimited arguments. Argument values containing whitespace should be quoted. The resulting process will be executed directly and will not be parsed by the shell.
  • If the application's stack is not io.paketo.stacks.tiny the contents of Procfile will be executed as a shell script.

Bindings

The buildpack optionally accepts the following bindings:

Key	Value	Description
Procfile	List of<process-type>: <command> entries	The entries from this Binding will be merged with those from the application's Procfile, if both are present. The commands from this Binding take precedence over the application's Procfile if there are duplicate process-types.

License

This buildpack is released under version 2.0 of the Apache License.

procfile's Issues

Provide a Procfile in a binding

The procfile buildpack currently detects a Procfile in the root of the directory structure provided to the buildpack. This works well in situations where the source code is being provided to the builder and buildpacks are building the application from source. The Procfile will be used to influence the image contents but will typically not end up in the generated image.

With Java applications, it is common for users to build the application and package it as a jar or war file then send the contents of the packaged app to the builder. In this scenario the Procfile must be packaged at the root of the jar or war file structure, and will be included in the generated image. This is not ideal, and it would be better if there were an alternate way to expose a Procfile to the buildpack.

Since a Procfile is intended to contain extra information to influence the generated image but should not be included in the generated image, it seems like a good fit for a binding. Would it be feasible to enhance this buildpack to support detecting the Procfile in a binding?

Releases with everything I need to include procfile in other meta buildpacks?

I was looking to add procfile to the ruby buildpack.toml but it does not publish releases paketo-buildpacks/ruby#56

I'm sorry that I'm confused -- I still don't think I get my head around what repos are components and what are meta buildpacks, and different repos have very different looking buildpack.toml files.

In the ruby toml https://github.com/paketo-community/ruby/blob/master/buildpack.toml each dependency looks like:

  [[metadata.dependencies]]
    id = "paketo-community/mri"
    sha256 = "0dbaf9ee3ba9897f5b9ebedbe54a0bb6f8b8aa14320d131070ae10ba460a1810"
    source = "https://github.com/paketo-community/mri/archive/v0.0.121.tar.gz"
    source_sha256 = "331359db395f73cd4d3302601c1bf1ee9f0c24d8e3edee949e5258e5dbcd5c25"
    stacks = ["io.buildpacks.stacks.bionic", "org.cloudfoundry.stacks.cflinuxfs3"]
    uri = "https://github.com/paketo-community/mri/releases/download/v0.0.121/mri-0.0.121.tgz"
    version = "0.0.121"

But https://github.com/paketo-buildpacks/java/blob/c55437c0ff489dc58789a4f9191a3ef638b0325c/buildpack.toml uses procfile buildpack but the file doesn't include the [[metadata.dependencies]] I need. So confusing.

But the procfile project does not cut releases of a procfile-1.3.6.tgz. Could this project's CI please spit out releases + sample TOML that I'd use to add to ruby's buildpack.toml?

Add support for the static stack

Describe the Enhancement

The static stack is even smaller than tiny. It's designed for using with static binaries like from Go or Rust. It has a different stack id, so we need to add a check for that here.

https://github.com/paketo-buildpacks/procfile/blob/main/procfile/build.go#L49

Motivation

The static stack is a place where folks might want to use a Procfile.

Support multi-architecture (ARM64) builds

In order to support multi-architecture builds in the project, we will need to set up buildpacks, builders, and stacks that work on ARM64.

The Procfile is a simple, lightweight first buildpack we could try to enable multi-arch builds for that doesn't require dependencies. As a result, we can use this buildpack to test multi-arch builders down the road.

Support Buildpack API Version 0.9

RFC-0093 pushes the decision if a shell is necessary from the lifecycle to the individual buildpacks.

Are there already ideas how to move the Procfile Buildpack to Buildpack API Version 0.9?

Possible Solution

1. Push the decision for using a shell back to the user. This would be a breaking change. Example:

some-command: bash -c "run-something"

2. Have some USE_SHELL environment variable which chooses the shell.
3. Have a helper-like binary which auto-detects the shell to use
4. Something else

Support Jammy Tiny Stack

Currently, this buildpack only sets the procfile processes as direct if the stack id matches the Ubuntu Bionic Tiny stack ID. Now that the Jammy Tiny Stack exists, this check should be updated to include the new Jammy Tiny stack id: "io.buildpacks.stacks.jammy.tiny"

Support Jammy Tiny stack

Paketo is working on implementing a Jammy Tiny stack: paketo-buildpacks/jammy-tiny-stack#1

In order for this buildpack to work properly with the stack, it'll need to use Direct processes if the stack ID matches io.buildpacks.stacks.jammy.tiny.

procfile/procfile/build.go

Line 49 in 3a6c8fd

if context.StackID == libpak.TinyStackID {