Compare commits

..

4 Commits

Author SHA1 Message Date
dependabot[bot] 0edf719b8b
Merge acacc3ea04 into cc6c6cdf1b 2025-08-12 13:48:39 +09:00
dependabot[bot] cc6c6cdf1b
Bump buildpacks/github-actions from 5.9.1 to 5.9.3 (#840)
Bumps [buildpacks/github-actions](https://github.com/buildpacks/github-actions) from 5.9.1 to 5.9.3.
- [Release notes](https://github.com/buildpacks/github-actions/releases)
- [Commits](https://github.com/buildpacks/github-actions/compare/v5.9.1...v5.9.3)

---
updated-dependencies:
- dependency-name: buildpacks/github-actions
  dependency-version: 5.9.3
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
2025-08-12 05:48:28 +01:00
Richard Schneeman 44292df114
Fix `launch.toml` in use-inline-buildpacks.md (#843)
The `launch.toml` command takes a slice and not a string

```
remote: ERROR: failed to build: toml: line 3 (last key "processes.command"): incompatible types: TOML value has type string; destination has type slice
```

Spec: d29ba81518/buildpack.md (launchtoml-toml)

Signed-off-by: Richard Schneeman <richard.schneeman+no-recruiters@gmail.com>
2025-08-12 05:47:14 +01:00
Richard Schneeman b927876fd3
Clear up `clean-env` docs (#841)
* Clear up `clean-env` docs

## Context

I was asked to validate that several buildpacks were correctly passing user-supplied environment variables to sub-processes for the purpose of configuring access to dependencies that require credentials.

The docs clearly state that a `buildpack.toml` with `clear-env` should have specific behavior regarding environment variable visibility, but it's not clear that it means that the `CNB_PLATFORM_DIR/env/` is ALWAYS provided and that `clear-env = false` means that information is merged into the current environment.

If you read it literally and you know that `$CNB_PLATFORM_DIR/env/` is a mechanism to provide the environment variables to a buildpack, you might interpret it as the ability to hide these platform envs from the buildpack. When really, it's saying "lifecycle will make things easy for you if you just want a firehose of all the envs, it will copy the user-provided ones into the current environment so you don't need to." It does this by default with the ability to opt out by setting `clear-env = true`.

## Change

I'm suggesting we tighten up the language here to make it clear that `$CNB_PLATFORM_DIR/env/` is always available, and that setting `clear-env = true` will tell the lifecycle to copy the contents of `CNB_PLATFORM_DIR/env/` into the current environment. Specific language suggestions pending. This logic is in several places:

- https://buildpacks.io/docs/for-buildpack-authors/how-to/write-buildpacks/clear-env/
- https://buildpacks.io/docs/reference/config/buildpack-config/
- https://buildpacks.io/docs/for-app-developers/how-to/build-inputs/configure-build-time-environment/

Signed-off-by: Schneems <richard.schneeman+foo@gmail.com>

* Fix vale failures

Signed-off-by: Schneems <richard.schneeman+foo@gmail.com>

---------

Signed-off-by: Schneems <richard.schneeman+foo@gmail.com>
2025-08-12 05:46:43 +01:00
5 changed files with 30 additions and 12 deletions

View File

@ -24,7 +24,7 @@ jobs:
- name: Install Dependencies - name: Install Dependencies
run: sudo apt-get install make curl jq run: sudo apt-get install make curl jq
- name: Install pack - name: Install pack
uses: buildpacks/github-actions/setup-pack@v5.9.1 uses: buildpacks/github-actions/setup-pack@v5.9.3
with: with:
pack-version: '0.36.0' pack-version: '0.36.0'
- name: Test - name: Test

View File

@ -11,7 +11,12 @@ Environment variables are a common way to configure various buildpacks at build-
<!--more--> <!--more-->
Below are a few ways you can do so. All of them will use our [samples] repo for simplicity. Below are a few ways you can do so. All of them use the [samples] repository for
simplicity. The following documentation assumes that all participating buildpack
either use `clear-env = false` as the default in their
[buildpack.toml](https://buildpacks.io/docs/reference/config/buildpack-config/),
or if they use `clear-env = true`, that they merge in filtered user supplied
environment variables.
### Using CLI arguments (`--env`) ### Using CLI arguments (`--env`)

View File

@ -50,7 +50,7 @@ find . -type f -name $(my_data_files) -delete
cat <<EOF > ${1}/launch.toml cat <<EOF > ${1}/launch.toml
[[processes]] [[processes]]
type = 'bash' type = 'bash'
command = 'bin/bash' command = ['bin/bash']
EOF EOF
""" """
``` ```

View File

@ -3,20 +3,30 @@ title="Clear the buildpack environment"
weight=99 weight=99
+++ +++
"Clearing" the buildpack environment with `clear-env` is the process of preventing end-users from customizing a buildpack's behavior through environment variables. "Clearing" the buildpack environment with `clear-env` is the process of preventing the lifecycle from automatically merging user-provided environment variables into the buildpack's executing process's environment variables.
<!--more--> <!--more-->
Buildpack authors may elect to clear user-provided environment variables when `bin/detect` and `bin/build` are executed. This is achieved by setting `clear-env` to `true` in [buildpack.toml](https://github.com/buildpacks/spec/blob/main/buildpack.md#buildpacktoml-toml); by default `clear-env` is set to `false`. User-provided environment variables are always written to disk at `$CNB_PLATFORM_DIR/env/` as "platform" environment variables and are available to a buildpack regardless of the `clear-env` setting. For example, if someone runs `pack build --env HELLO=world`, there is always a `$CNB_PLATFORM_DIR/env/hello` file with the contents of `world`.
* When `clear-env` is set to `true` for a given buildpack, the `lifecycle` will not set user-provided environment variables when running `/bin/detect` or `/bin/build`. By default with `clear-env = false`, the lifecycle automatically copies these user-provided environment variables into the current process environment when executing `/bin/detect` and `/bin/build`. This provides a comprehensive stream of all user environment variables for a buildpack that wants easy access to user customization.
* If a buildpack does allow customization by the end-user through the environment (`clear-env` is `false`), there is a special convention for naming the environment variables recognized by the buildpack, shown in the following table:
| Env Variable | Description | Detect | Build | Launch | Setting `clear-env = true` in the [buildpack.toml](https://github.com/buildpacks/spec/blob/main/buildpack.md#buildpacktoml-toml) prevents this automatic merging, giving a buildpack complete control over which user-provided environment variables to use. This provides maximum isolation and predictability for a buildpack that wants to be more selective about environment variable usage.
For example, if a user has specified the `PATH` environment variable, then a buildpack written in bash might unexpectedly find that tools it relies on such as `cp` aren't the ones it expects. However, setting `clear-env = true` won't change runtime behavior.
* When you set `clear-env` to `true` for a given buildpack, the `lifecycle` writes user-provided environment variables to disk at `$CNB_PLATFORM_DIR/env/` but it won't copy those variables into the buildpack process when running `/bin/detect` or `/bin/build`.
* If a buildpack uses `clear-env = false` which allows customization by the end-user through the environment, there is a special convention for naming the environment variables recognized by the buildpack, shown in the following table:
| Environment Variable | Description | Detect | Build | Launch |
|------------------------|---------------------------------------------------|--------|-------|--------| |------------------------|---------------------------------------------------|--------|-------|--------|
| `BP_*` | User-provided variable for buildpack | [x] | [x] | | | `BP_*` | User-provided variable for buildpack | [x] | [x] | |
| `BPL_*` | User-provided variable for exec.d | | | [x] | | `BPL_*` | User-provided variable for exec.d | | | [x] |
### Further Reading Buildpack that use `clear-env = true` should filter and export environment variables from `$CNB_PLATFORM_DIR/env/` while warning on the filtered variables. Emitting a warning helps users understand if runtime behavior differs from build time behavior. Sourcing the user environment variables is critical to allowing sub-processes access to credentials.
For more about how environment variables are specified by end-users, see the page for how to [customize buildpack behavior with build-time environment variables](https://buildpacks.io/docs/for-app-developers/how-to/build-inputs/configure-build-time-environment/). For example, if a private gem server hosted on `gems.example.com` needs access in a sub-process such as `bundle install`, the user must provide `BUNDLE_GEMS__EXAMPLE__COM=<username>:<password>`. If `clear-env = true` and the buildpack doesn't use platform environment variables, then trying to access that resource would fail.
### Further reading
For more about how end-users specify environment variables, see the page for how to [customize buildpack behavior with build-time environment variables](https://buildpacks.io/docs/for-app-developers/how-to/build-inputs/configure-build-time-environment/).

View File

@ -29,7 +29,10 @@ The schema is as follows:
Human readable name. Human readable name.
- **`clear-env`** _(boolean, optional, default: `false`)_\ - **`clear-env`** _(boolean, optional, default: `false`)_\
Clears user-defined environment variables when `true` on executions of `bin/detect` and `bin/build`. When `true`, prevents the lifecycle from automatically merging user-provided
environment variables into the buildpack process environment during
`bin/detect` and `bin/build`. User-provided environment variables remain
available at `$CNB_PLATFORM_DIR/env/` regardless of this setting.
- **`homepage`** _(string, optional)_\ - **`homepage`** _(string, optional)_\
Buildpack homepage. Buildpack homepage.