Skip to content

Commit

Permalink
Merge branch 'main' into fix-pack-publish-buildpack-link
Browse files Browse the repository at this point in the history
  • Loading branch information
enrichman committed Aug 8, 2024
2 parents b3cb150 + 34caba7 commit 70f5fc4
Show file tree
Hide file tree
Showing 5 changed files with 1,525 additions and 12 deletions.
44 changes: 32 additions & 12 deletions text/0096-remove-stacks-mixins.md
Original file line number Diff line number Diff line change
Expand Up @@ -41,19 +41,19 @@ Instead of a stack ID, runtime and build-time base images must contain the follo
- OS (e.g., "linux", `$GOOS`), specified as `os` in the base image `config`
- Architecture (e.g., "arm", `$GOARCH`), specified as `architecture` in the base image `config`
- Architecture Variant (optional) (e.g., "v6", `$GOARM`), specified as `variant` in the base image `config`
- Distribution (optional) (e.g., "ubuntu", `$ID`), specified as a label `io.buildpacks.distribution.name`
- Version (optional) (e.g., "18.04", `$VERSION_ID`), specified as a label `io.buildpacks.distribution.version`
- Distribution (optional) (e.g., "ubuntu", `$ID`), specified as a label `io.buildpacks.base.distro.name`
- Version (optional) (e.g., "18.04", `$VERSION_ID`), specified as a label `io.buildpacks.base.distro.version`

Additionally, the runtime base may contain the following metadata:
- Target ID (optional) (e.g., "minimal"), specified as a label `io.buildpacks.id`
- Target ID (optional) (e.g., "minimal"), specified as a label `io.buildpacks.base.id`

OS, Architecture, and Architecture Variant must be valid identifiers as defined in the [OCI Image specification](https://github.com/opencontainers/image-spec/blob/main/config.md).

Target ID is an identifier specified on the runtime base image that must be provided to buildpacks as `CNB_TARGET_ID` during the build process.
This allows buildpacks to change their behavior if a run image is selected (e.g., distroless) that has special properties outside of OS, architecture, etc.

For Linux-based images, each field should be canonicalized against values specified in `/etc/os-release` (`$ID` and `$VERSION_ID`).
The `os.version` field in an base image `config` may contain combined distribution and version information, but it is not used by the lifecycle.
The `os.version` field in a base image `config` may contain combined distribution and version information, but it is not used by the lifecycle.

For Windows-based images, Distribution should be empty. Version should be the [suggested value of `os.version`](https://github.com/opencontainers/image-spec/blob/main/config.md#properties) in the OCI spec (e.g., `10.0.14393.1066`).

Expand Down Expand Up @@ -81,17 +81,17 @@ versions = ["18.04", "20.04"]
[[targets]]
os = "linux"
arch = "amd64"
[[targets.distributions]]
[[targets.distros]]
name = "ubuntu"
versions = ["14.04", "16.04"]
version = "16.04"

[[targets]]
os = "linux"
arch = "arm"
variant = "v6"
[[targets.distributions]]
[[targets.distros]]
name = "ubuntu"
versions = ["14.04", "16.04"]
version = "16.04"
```

## Runtime Metadata
Expand Down Expand Up @@ -153,11 +153,11 @@ If the newly-specified field values are missing, the lifecycle and pack may used
```
config.os = "linux"
config.architecture = "amd64"
io.buildpacks.distribution.name = "ubuntu"
io.buildpacks.distribution.version = "18.04"
io.buildpacks.base.distro.name = "ubuntu"
io.buildpacks.base.distro.version = "18.04"
```

Moving forward it's encouraged for buildpack authors to support both `[[stacks]]` and `[[targets]]` sections in `buildpack.toml` for maximum compatibility. In order to ease this process for those using the `io.buildpacks.stacks.bionic`, lifecycle will translate any section that sets this as on of the `stacks`:
Moving forward it's encouraged for buildpack authors to support both `[[stacks]]` and `[[targets]]` sections in `buildpack.toml` for maximum compatibility. In order to ease this process for those using the `io.buildpacks.stacks.bionic`, lifecycle will translate any section that sets this as one of the `stacks`:

```toml
[[stacks]]
Expand All @@ -170,7 +170,7 @@ to
[[targets]]
os = "linux"
arch = "amd64"
[[targets.distributions]]
[[targets.distros]]
name = "ubuntu"
versions = ["18.04"]
```
Expand Down Expand Up @@ -210,3 +210,23 @@ rename x86_64 -> amd64 in keeping with all other usages of arch. descriptors.
### Motivation

This is how we do it everywhere else, this is the way.

## Amended
### Meta
[meta-1]: #meta-1
- Name: Rename Docker labels and `buildpack.toml` table names
- Start Date: 2024-04-08
- Author(s): @edmorley
- Amendment Pull Request: [rfcs#310](https://github.com/buildpacks/rfcs/pull/310)

### Summary

Changes were made to the Docker label and `buildpack.toml` table names between when this RFC was written and the changes were made to the spec in [spec#365](https://github.com/buildpacks/spec/pull/365), which have now been backported to the RFC:

- The `io.buildpacks.distributions.*` Docker labels were renamed to `io.buildpacks.base.distro.*`.
- The `io.buildpacks.id` Docker label was renamed to `io.buildpacks.base.id`.
- The `buildpack.toml` table `[[targets.distributions]]` was renamed to `[[targets.distros]]` and the `versions` field within it renamed to `version` (along with its type changing from an array to a string).

### Motivation

To prevent use of the wrong Docker label or `buildpack.toml` table names, if users base their implementations on the RFC rather than reading the spec.
131 changes: 131 additions & 0 deletions text/0126-creator-skip-sbom.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,131 @@
# Meta
[meta]: #meta
- Name: Enable CNB_SKIP_SBOM IN /cnb/lifecycle/creator
- Start Date: (fill in today's date: 2023-10-17)
- Author(s): kritkasahni-google
- Status: Approved
- RFC Pull Request:
- CNB Pull Request:
- CNB Issue:
- Supersedes: N/A

# Summary
[summary]: #summary

Enable CNB_SKIP_SBOM IN /cnb/lifecycle/creator to skip restoring SBOM layer from previous app image. We support CNB_SKIP_LAYERS in analyzer which does the same thing and we should support the same in creator also.

# Definitions
[definitions]: #definitions
* lifecycle: software that orchestrates a CNB build.
* creator: executes all the lifecycle phases one by one in order.
* analyzer: lifecycle phase that restores SBOM layer from previous app image.
* restorer: lifecycle phase that restores layers from cache.
* SBOM: a software bill of materials (SBOM) is a list of all the components that make up the app image.

# Motivation
[motivation]: #motivation

To skip restoring SBOM layer from previous image when platform executes lifecycle by calling /cnb/lifecycle/creator. Restoring SBOM layer from previous app image can cause degraded build latency but if buildpack logic does not rely on SBOM from previous app image then should be able to skip restoring it.

# What it is
[what-it-is]: #what-it-is

CNB_SKIP_LAYERS is used by /cnb/lifecycle/analyzer to skip restoring SBOM layer from previous app image.
Need a similar mechanism for /cnb/lifecyle/creator specifically to skip restoring only the SBOM layer.

The target personas affected by this change are:

- **buildpack user**: if buildpacks don't rely on reusing SBOM layer then buildpack user should ideally see improved build latency by skipping SBOM restoration but reusing other layers from previous app image.
- **Platform implementors**: they will choose to skip restoring SBOM by providing CNB_SKIP_SBOM to trigger /cnb/lifecycle/creator.


# How it Works
[how-it-works]: #how-it-works

Similar to how CNB_SKIP_LAYERS is handled in analyzer whether SBOM needs to be [restored](https://github.com/buildpacks/lifecycle/blob/292aa492a72f4e180bb92d109a73ebf7c8a0451d/phase/analyzer.go#L38) or [not](https://github.com/buildpacks/lifecycle/blob/292aa492a72f4e180bb92d109a73ebf7c8a0451d/phase/analyzer.go#L30) today, CNB_SKIP_SBOM will be be handled in same way in analyzer.
At the platform level, it would be input same way as CNB_SKIP_LAYERS [here](https://github.com/buildpacks/lifecycle/blob/292aa492a72f4e180bb92d109a73ebf7c8a0451d/platform/defaults.go#L184) and [handled](https://github.com/buildpacks/lifecycle/blob/main/platform/lifecycle_inputs.go#L82) like:-


```
var skipSBOM bool
if boolEnv(EnvSkipSBOM){
skipSBOM = true
}
```

In the analyzer,

```
analyzer := &Analyzer{
Logger: logger,
SBOMRestorer: &layer.NopSBOMRestorer{},
PlatformAPI: f.platformAPI,
}
...
if f.platformAPI.AtLeast("0.8") && !inputs.SkipLayers && !inputs.SkipSBOM {
analyzer.SBOMRestorer = &layer.DefaultSBOMRestorer{
LayersDir: inputs.LayersDir,
Logger: logger,
}
}
```

# Migration
[migration]: #migration

CNB_SKIP_SBOM/<skip-sbom> will be an optional input to /cnb/lifecycle/creator, and will be false by default. We maybe need to add a new API option for buildpack users, to choose whether this should be enabled.

# Drawbacks
[drawbacks]: #drawbacks

N/A

# Alternatives
[alternatives]: #alternatives

Platforms that execute lifecycle today via /cnb/lifecycle/creator are unable to skip restoring SBOM layer from previous app image unless they skip reusing previous app image entirely.

# Prior Art
[prior-art]: #prior-art

We already support enabling CNB_SKIP_LAYERS in /cnb/lifecycle/analyzer and /cnb/lifecycle/restorer, and CNB_SKIP_RESTORE in /cnb/lifecycle/creator.
* CNB_SKIP_LAYERS in /cnb/lifecycle/analyzer to skip restoring SBOM from previous app image.
* CNB_SKIP_LAYERS in /cnb/lifecycle/restorer to skip reusing previous app image layers entirely.
* CNB_SKIP_RESTORE in /cnb/lifecycle/creator to skips restoring SBOM plus all other layers entirely from previous app image.

# Unresolved Questions
[unresolved-questions]: #unresolved-questions

N/A

# Spec. Changes (OPTIONAL)
[spec-changes]: #spec-changes
This new feature will affect the API of [Create](https://buildpacks.io/docs/concepts/components/lifecycle/create/) phase by adding the following fields.

Back to API changes, we will add a new flag to control this.

| Input | Environment Variable | DefaultValue | Description |
|----------------|-----------------------|--------------|----------------------------------------------|
| `<skip-sbom>` | `CNB_SKIP_SBOM` | `false` | Skip SBOM restoration |

# History
[history]: #history

<!--
## Amended
### Meta
[meta-1]: #meta-1
- Name: (fill in the amendment name: Variable Rename)
- Start Date: (fill in today's date: YYYY-MM-DD)
- Author(s): (Github usernames)
- Amendment Pull Request: (leave blank)
### Summary
A brief description of the changes.
### Motivation
Why was this amendment necessary?
--->
131 changes: 131 additions & 0 deletions text/0127-extension-layer.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,131 @@
# Meta
[meta]: #meta
- Name: Add extension layer to exchange data
- Start Date: 2023-10-09
- Author(s): [c0d1ngm0nk3y](https://github.com/c0d1ngm0nk3y), [pbusko](https://github.com/pbusko)
- Status: Approved
- RFC Pull Request:
- CNB Pull Request:
- CNB Issue:
- Related: [RFC#0105 Support Dockerfiles](https://github.com/buildpacks/rfcs/blob/main/text/0105-dockerfiles.md)
- Supersedes: N/A

# Summary
[summary]: #summary

This RFC introduces support for Extension configurable context to allow data transfer between the build environment and the Kaniko execution.

# Motivation
[motivation]: #motivation

This change allows extensions to create their own context for the extend phase during the generation phase. Additionally, it ensures that extension output does not inadvertently interfere with other extension or buildpack layers during the build, and it does not unintentionally become part of the final application image.

This would allow distroless run images to be extended.

# What it is
[what-it-is]: #what-it-is

This follows up on RFC-0105 and proposes that during the execution of the extension's `./bin/generate`, an extension is allowed to write arbitrary data to the `context` folder within its exclusive output directory. This data then becomes accessible during the execution of the `extend` phase via Kaniko build context. The content of these extension-specific context is ignored at build and launch time, it serves only the extension phase.

# How it Works
[how-it-works]: #how-it-works

- Before execution of the `./bin/generate`, the lifecycle will create a distinct writable layer `$CNB_GENERATED_DIR/<extension-id>` for each extension which passed detection.
- The `$CNB_GENERATED_DIR/<extension-id>` is provided to the `./bin/generate` as `<output>` (`$CNB_OUTPUT_DIR`) directory.
- In addition to the files specified in [RFC#0105](https://github.com/buildpacks/rfcs/blob/main/text/0105-dockerfiles.md), the extension may create the following folders with an arbitrary content:

either:

- `<output>/context`

or the image-specific folders:

- `<output>/context.run`
- `<output>/context.build`

If the `<output>/context` is provided together with any of the image-specific folders the detection phase must fail.
- If the folder `<output>/context` is present it will be set as Kaniko build context during the `extend` phase of the build and run images.
- If the folder `<output>/context.run` is present it will be set as Kaniko build context during the `extend` phase of the run image only.
- If the folder `<output>/context.build` is present it will be set as Kaniko build context during the `extend` phase of the build image only.
- If none of these folders is not present, Kaniko build context defaults to the `<app>` folder.

The `$CNB_GENERATED_DIR/<extension-id>` folders will not be included in the final image by the lifecycle.

### Example: Extend distroless run image with Debian packages.

This example extension would allow to install `tar` package on the run image without package manager (distroless image). The extension contains `./bin/generate` and `./bin/custom-installer` file, which installs `.deb` files.

##### `./bin/generate`

```bash
#!/bin/sh

mkdir -p ${CNB_OUTPUT_DIR}/context.run

cp ${CNB_EXTENSION_DIR}/bin/custom-installer ${CNB_OUTPUT_DIR}/context.run/
curl -o ${CNB_OUTPUT_DIR}/context.run/tar.deb http://security.ubuntu.com/ubuntu/pool/main/t/tar/tar_1.34+dfsg-1ubuntu0.1.22.04.1_amd64.deb

cat >> "${CNB_OUTPUT_DIR}/run.Dockerfile" <<EOL
ARG base_image
FROM \${base_image}
ARG build_id=0
ADD custom-installer .
ADD tar.deb .
RUN ./custom-installer -p ./tar.deb
EOL
```

# Migration
[migration]: #migration

- No breaking changes were identified

# Drawbacks
[drawbacks]: #drawbacks

Why should we *not* do this?

N/A

# Alternatives
[alternatives]: #alternatives

- Allow multi-stage Dockerfiles

# Prior Art
[prior-art]: #prior-art

Discuss prior art, both the good and bad.

# Unresolved Questions
[unresolved-questions]: #unresolved-questions

- Should the `./bin/generate` be executed during the `extend` phase instead of the `detect` phase?

# Spec. Changes (OPTIONAL)
[spec-changes]: #spec-changes

This RFC requires changes to the layers metadata and the `extend` phase:

- the `$CNB_OUTPUT_DIR` must point to the `$CNB_GENERATED_DIR/<extension-id>` folder instead of a temporary directory.
- allow optional folders `$CNB_GENERATED_DIR/<extension-id>/context`, `$CNB_GENERATED_DIR/<extension-id>/context.run` and `$CNB_GENERATED_DIR/<extension-id>/context.build` with an arbitrary content to be provided by extension.
- if the context folders are present, kaniko context should be set to the corresponding folder instead of the `<app>` (following the rules defined in [#how-it-works](#how-it-works)).

<!--
## Amended
### Meta
[meta-1]: #meta-1
- Name: (fill in the amendment name: Variable Rename)
- Start Date: (fill in today's date: YYYY-MM-DD)
- Author(s): (Github usernames)
- Amendment Pull Request: (leave blank)
### Summary
A brief description of the changes.
### Motivation
Why was this amendment necessary?
--->
Loading

0 comments on commit 70f5fc4

Please sign in to comment.