Merge branch 'master' into bionic-mixins

Signed-off-by: Joe Kutner <jpkutner@gmail.com>

0000-template.md

@@ -59,3 +59,9 @@ Discuss prior art, both the good and bad.
 - What parts of the design do you expect to be resolved before this gets merged?
 - What parts of the design do you expect to be resolved through implementation of the feature?
 - What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC?
+
+# Spec. Changes (OPTIONAL)
+[spec-changes]: #spec-changes
+Does this RFC entail any proposed changes to the core specifications or extensions? If so, please document changes here.
+Examples of a spec. change might be new lifecycle flags, new `buildpack.toml` fields, new fields in the buildpackage label, etc.
+This section is not intended to be binding, but as discussion of an RFC unfolds, if spec changes are necessary, they should be documented here.

CODEOWNERS

@@ -1 +1 @@
-* @buildpack/owners
+* @buildpacks/core-team

text/0001-pack-suggest-stacks.md

@@ -2,8 +2,8 @@
 [meta]: #meta
 - Name: Suggest Stacks
 - Start Date: 2019-04-25
-- CNB Pull Request: [rfcs#4](https://github.com/buildpack/rfcs/pull/4), [pack#190](https://github.com/buildpack/pack/pull/190)
-- CNB Issue: [pack#156](https://github.com/buildpack/pack/issues/156)
+- CNB Pull Request: [rfcs#4](https://github.com/buildpacks/rfcs/pull/4), [pack#190](https://github.com/buildpacks/pack/pull/190)
+- CNB Issue: [pack#156](https://github.com/buildpacks/pack/issues/156)
 - Supersedes: N/A
 
 # Summary

text/0002-pack-logging-refactor.md

@@ -2,7 +2,7 @@
 [meta]: #meta
 - Name: Pack Logging Interface
 - Start Date: 2019-05-06
-- CNB Pull Request: [rfcs#6](https://github.com/buildpack/rfcs/pull/6), [pack#182](https://github.com/buildpack/pack/pull/182)
+- CNB Pull Request: [rfcs#6](https://github.com/buildpacks/rfcs/pull/6), [pack#182](https://github.com/buildpacks/pack/pull/182)
 - CNB Issue: (leave blank)
 - Supersedes: N/A
 
@@ -25,7 +25,7 @@ Pack uses its own internal logging code, and does not leverage any of the existi
 # How it Works
 [how-it-works]: #how-it-works
 
-Remove the custom logging code for pack.  All pack functions that take a pointer to the concrete `logging.Logger`  structure will be modified to take a simple logging interface as an argument.  Given the proliferation of logging packages in the Go ecosystem it may be impossible to design an interface that works with all of them. However by supplying a very simple interface the current logging requirement of pack can be met, and most logging libraries could be adapted to work with pack with little or no modification.  
+Remove the custom logging code for pack.  All pack functions that take a pointer to the concrete `logging.Logger`  structure will be modified to take a simple logging interface as an argument.  Given the proliferation of logging packages in the Go ecosystem it may be impossible to design an interface that works with all of them. However by supplying a very simple interface the current logging requirement of pack can be met, and most logging libraries could be adapted to work with pack with little or no modification.
 
 ```
 type Logger interface {

text/0003-pack-inspect-image.md

@@ -2,7 +2,7 @@
 [meta]: #meta
 - Name: Inspect Image
 - Start Date: 2019-04-25
-- CNB Pull Request: [rfcs#5](https://github.com/buildpack/rfcs/pull/5)
+- CNB Pull Request: [rfcs#5](https://github.com/buildpacks/rfcs/pull/5)
 - CNB Issue:
 - Supersedes: N/A
 
@@ -115,7 +115,7 @@ In the future we could also provide flags to change the output format (e.g `-o y
 
 `exporter` will add the bill-of-materials and the process types to the `io.buildpacks.lifecycle.metadata` label by adding `bom` and `processes` keys respectively.
 
-`pack` will read all necessary information from the metadata label and display it to the user. 
+`pack` will read all necessary information from the metadata label and display it to the user.
 
 # Drawbacks
 [drawbacks]: #drawbacks

text/0004-rfc-process.md

@@ -2,7 +2,7 @@
 [meta]: #meta
 - Name: RFC Process
 - Start Date: 2019-04-09
-- CNB Pull Request: [rfcs#1](https://github.com/buildpack/rfcs/pull/1), [rfcs#7](https://github.com/buildpack/rfcs/pull/7)
+- CNB Pull Request: [rfcs#1](https://github.com/buildpacks/rfcs/pull/1), [rfcs#7](https://github.com/buildpacks/rfcs/pull/7)
 - CNB Issue: (leave blank)
 - Supersedes: N/A
 
@@ -57,7 +57,7 @@ If you submit a pull request the team deems warrants an RFC, it will be politely
 
 To get an RFC into Cloud Native Buildpacks, first the RFC needs to be merged into the RFC repo. Once an RFC is merged, it's considered 'active' and may be implemented to be included in the project. These steps will get an RFC to be considered:
 
-- Fork the RFC repo: <https://github.com/buildpack/rfcs>
+- Fork the RFC repo: <https://github.com/buildpacks/rfcs>
 - Copy `0000-template.md` to `text/0000-my-feature.md` (where 'my-feature' is descriptive. don't assign an RFC number yet).
 - Fill in RFC. Any section can be marked as "N/A" if not applicable.
 - Submit a pull request. The pull request is the time to get review of the proposal from the larger community.

text/0005-contractual-build-plan.md

@@ -1,8 +1,8 @@
-# Meta 
+# Meta
 [meta]: #meta
 - Name: Contractual Build Plan
 - Start Date: 2019-04-12
-- CNB Pull Requests: [rfcs#12](https://github.com/buildpack/rfcs/pull/12), [spec#52](https://github.com/buildpack/spec/pull/52), [lifecycle#149](https://github.com/buildpack/lifecycle/pull/149)
+- CNB Pull Requests: [rfcs#12](https://github.com/buildpacks/rfcs/pull/12), [spec#52](https://github.com/buildpacks/spec/pull/52), [lifecycle#149](https://github.com/buildpacks/lifecycle/pull/149)
 - CNB Issues: (lifecycle issues to follow)
 
 # Motivation
@@ -47,7 +47,7 @@ It affects buildpack developers who implement modular, interdependent buildpacks
 - Multiple buildpacks may require or provide the same dependency.
 - `/bin/build` no longer receives a build plan on stdin.
 - `/bin/build`'s build plan argument contains required dependencies that it provides.
-- `/bin/build` may refine its build plan to contain additional dependency metadata. 
+- `/bin/build` may refine its build plan to contain additional dependency metadata.
 - `/bin/build` may remove all entries for a dependency in its build plan to allow a subsequent buildpack to provide that dependency.
 
 ## Examples
@@ -111,7 +111,7 @@ packages = ["..."]
 
 2. How can a buildpack require either of two different dependencies, but not both?
 
-   With the [distribution spec](https://github.com/buildpack/rfcs/blob/dist-spec/0000-spec-distribution.md), complex logic can be expressed by multiple buildpacks that live in the same repository. These buildpacks may have the same source.
+   With the [distribution spec](https://github.com/buildpacks/rfcs/blob/dist-spec/0000-spec-distribution.md), complex logic can be expressed by multiple buildpacks that live in the same repository. These buildpacks may have the same source.
 
 # Unanswered Questions
 [unanswered-questions]: #unanswered-questions

text/0006-stage-specific-mixins.md

@@ -1,8 +1,8 @@
-# Meta 
+# Meta
 [meta]: #meta
-- Name: Stage-specific Mixins 
+- Name: Stage-specific Mixins
 - Start Date: 2019-06-13
-- CNB Pull Requests: [rfcs#13](https://github.com/buildpack/rfcs/pull/13), [spec#54](https://github.com/buildpack/spec/pull/54)
+- CNB Pull Requests: [rfcs#13](https://github.com/buildpacks/rfcs/pull/13), [spec#54](https://github.com/buildpacks/spec/pull/54)
 - CNB Issues: (lifecycle issues to follow)
 
 
@@ -14,7 +14,7 @@ This proposal makes it easier to extend stack images with mixins.
 # What it is
 [what-it-is]: #what-it-is
 
-This RFC proposes a method for annotating mixins that are necessary during build or launch but not for both stages.  
+This RFC proposes a method for annotating mixins that are necessary during build or launch but not for both stages.
 
 # How it Works
 [how-it-works]: #how-it-works

text/0007-spec-distribution.md

@@ -1,8 +1,8 @@
-# Meta 
+# Meta
 [meta]: #meta
 - Name: Buildpack Distribution Specification
 - Start Date: 2019-04-12
-- CNB Pull Requests: [rfcs#11](https://github.com/buildpack/rfcs/pull/11), [spec#53](https://github.com/buildpack/spec/pull/53), [lifecycle#149](https://github.com/buildpack/lifecycle/pull/149), [pack#243](https://github.com/buildpack/pack/issues/243)
+- CNB Pull Requests: [rfcs#11](https://github.com/buildpacks/rfcs/pull/11), [spec#53](https://github.com/buildpacks/spec/pull/53), [lifecycle#149](https://github.com/buildpacks/lifecycle/pull/149), [pack#243](https://github.com/buildpacks/pack/issues/243)
 - CNB Issues: (lifecycle issues to follow)
 
 
@@ -144,7 +144,7 @@ Next, the 2-D ordering of buildpacks is derived as follows:
 
 Where:
 - O and P are buildpacks IDs referencing buildpacks that compose other buildpack IDs.
-- A through H are buildpack IDs referencing executable buildpacks. 
+- A through H are buildpack IDs referencing executable buildpacks.
 
 Given:
 
@@ -169,7 +169,7 @@ We propose:
 <img src="http://tex.s2cms.ru/svg/%0A%5Cbegin%7Bbmatrix%7D%0AE%2C%20%26%20O%2C%20%26%20F%0A%5Cend%7Bbmatrix%7D%20%3D%20%0A%5Cbegin%7Bbmatrix%7D%0AE%2C%20%26%20A%2C%20%26%20B%2C%20%26%20F%20%5C%5C%0AE%2C%20%26%20C%2C%20%26%20D%2C%20%26%20F%20%5C%5C%0A%5Cend%7Bbmatrix%7D%0A" alt="
 \begin{bmatrix}
 E, &amp; O, &amp; F
-\end{bmatrix} = 
+\end{bmatrix} =
 \begin{bmatrix}
 E, &amp; A, &amp; B, &amp; F \\
 E, &amp; C, &amp; D, &amp; F \\
@@ -179,7 +179,7 @@ E, &amp; C, &amp; D, &amp; F \\
 <img src="http://tex.s2cms.ru/svg/%0A%5Cbegin%7Bbmatrix%7D%0AO%2C%20%26%20P%0A%5Cend%7Bbmatrix%7D%20%3D%20%0A%5Cbegin%7Bbmatrix%7D%0AA%2C%20%26%20B%2C%20%26%20E%2C%20%26%20F%20%5C%5C%0AA%2C%20%26%20B%2C%20%26%20G%2C%20%26%20H%20%5C%5C%0AC%2C%20%26%20D%2C%20%26%20E%2C%20%26%20F%20%5C%5C%0AC%2C%20%26%20D%2C%20%26%20G%2C%20%26%20H%20%5C%5C%0A%5Cend%7Bbmatrix%7D%0A" alt="
 \begin{bmatrix}
 O, &amp; P
-\end{bmatrix} = 
+\end{bmatrix} =
 \begin{bmatrix}
 A, &amp; B, &amp; E, &amp; F \\
 A, &amp; B, &amp; G, &amp; H \\
@@ -270,7 +270,7 @@ These properties will be specified in a `builder.toml` file. This file is a conf
 uri = "https://example.com/nodejs.tgz"
 
 [[packages]]
-ref = "registry.example.com/ruby" 
+ref = "registry.example.com/ruby"
 
 [[order]]
 group = [
@@ -300,10 +300,10 @@ If `order` is not specified, the first buildpackage in `packages` becomes the de
 
 3. For simplicity, should builders be restricted to a single buildpackage, no blobs, and no order definition?
    Suggestion: no, the proposed model simplifies the workflow.
-   
+
 4. Should we remove symlinks in a buildpackage to buildpacks that don't match a buildpackage stack?
    Suggestion: no, this makes dynamic builder generation difficult.
-   
+
 5. Is `package.toml` really necessary?
    Suggestion: it's necessary until we develop a buildpack registry that allows you to download a buildpack based on its ID.
    Once there is a registry, we should deprecate `package.toml` so packages can be generated directly from `buildpack.toml`.

text/0008-buildpack-config-for-dist.md

@@ -2,7 +2,7 @@
 [meta]: #meta
 - Name: Buildpack Configuration for Distribution
 - Start Date: July 22, 2019
-- CNB Pull Request: [rfcs#15](https://github.com/buildpack/rfcs/pull/15)
+- CNB Pull Request: [rfcs#15](https://github.com/buildpacks/rfcs/pull/15)
 - CNB Issue: (leave blank)
 - Supersedes: N/A
 
@@ -15,8 +15,8 @@ concerns of defining a buildpack and managing configuration of buildpacks.
 # Motivation
 [motivation]: #motivation
 
-In the approval of the [Distribution Spec](https://github.com/buildpack/rfcs/blob/master/text/0007-spec-distribution.md),
-we landed on a [compromise that no one was really happy with](https://github.com/buildpack/rfcs/pull/11#issuecomment-510483638).
+In the approval of the [Distribution Spec](https://github.com/buildpacks/rfcs/blob/master/text/0007-spec-distribution.md),
+we landed on a [compromise that no one was really happy with](https://github.com/buildpacks/rfcs/pull/11#issuecomment-510483638).
 We now propose a new `buildpack.toml` schema that will, hopefully, satisfy all parties.
 
 The Distribution Spec defines a `buildpack.toml` schema containing an array of `[[buildpacks]]` that may include references to buildpacks in a registry or a path to a buildpack in the same repo. For example:
@@ -91,7 +91,7 @@ group = [
 The `id` and `version` pair will be resolved to a buildpack by the platform.
 
 ## Optional Build Plan Groups
-To simplify `buildpack.toml`, this RFC will also be extending the [Contractual Build Plan RFC](https://github.com/buildpack/rfcs/blob/master/text/0005-contractual-build-plan.md) to include the ability to add additional groupings of `provides` and `requires` inside of a `[[or]]` Array.
+To simplify `buildpack.toml`, this RFC will also be extending the [Contractual Build Plan RFC](https://github.com/buildpacks/rfcs/blob/master/text/0005-contractual-build-plan.md) to include the ability to add additional groupings of `provides` and `requires` inside of a `[[or]]` Array.
 
 ```toml
 [[or]]
@@ -107,7 +107,7 @@ The `[[or]]` Array is optional, but the top-level `[[requires]]` and `[[provides
 
 For a given buildpack group, a sequence of trials is generated by selecting a single potential Build Plan from each buildpack in a left-to-right, depth-first order. The group fails to detect if all trials fail to detect.
 
-This supports the use case described in the discussion of the [Distribution Spec](https://github.com/buildpack/rfcs/pull/12#issuecomment-504781945), by providing a single buildpack that can generate two different build plan groupings.
+This supports the use case described in the discussion of the [Distribution Spec](https://github.com/buildpacks/rfcs/pull/12#issuecomment-504781945), by providing a single buildpack that can generate two different build plan groupings.
 
 # How it Works
 [how-it-works]: #how-it-works
@@ -219,7 +219,7 @@ In this way, the `buildpack.toml` can be used directly (without specifiying a `-
 # Prior Art
 [prior-art]: #prior-art
 
-- The `buildpack.toml` definition in [Distribution Spec](https://github.com/buildpack/rfcs/blob/master/text/0007-spec-distribution.md)
+- The `buildpack.toml` definition in [Distribution Spec](https://github.com/buildpacks/rfcs/blob/master/text/0007-spec-distribution.md)
 
 # Unresolved Questions
 [unresolved-questions]: #unresolved-questions

text/0009-auto-load-user-provided-environment-variables.md

@@ -1,8 +1,8 @@
-# Meta 
+# Meta
 [meta]: #meta
 - Name: Auto-load User-provided Environment Variables
 - Start Date: 2019-06-17
-- CNB Pull Requests: [rfcs#14](https://github.com/buildpack/rfcs/pull/14), [spec#55](https://github.com/buildpack/spec/pull/55), [lifecycle#163](https://github.com/buildpack/lifecycle/pull/163)
+- CNB Pull Requests: [rfcs#14](https://github.com/buildpacks/rfcs/pull/14), [spec#55](https://github.com/buildpacks/spec/pull/55), [lifecycle#163](https://github.com/buildpacks/lifecycle/pull/163)
 - CNB Issues: (lifecycle issues to follow)
 
 
@@ -21,7 +21,7 @@ This RFC proposes that user-provided environment variable be loaded by default.
 
 User-provided build-time environment variables are loaded in the detection and build environment automatically unless `clear-env = true` is specified in the buildpack's entry in `buildpack.toml`. In both cases, the environment variables continue to be available in `<platform>/env/`.
 
-If any [lifecycle-provided env var](https://github.com/buildpack/spec/blob/master/buildpack.md#provided-by-the-lifecycle) is specified by the user, and `clear-env = true` is not set, then the user-provided value is prepended immediately before each `/bin/build` invocation, so that the value precedes any layer-provided values.
+If any [lifecycle-provided env var](https://github.com/buildpacks/spec/blob/master/buildpack.md#provided-by-the-lifecycle) is specified by the user, and `clear-env = true` is not set, then the user-provided value is prepended immediately before each `/bin/build` invocation, so that the value precedes any layer-provided values.
 
 # Questions
 [questions]: #questions

text/0010-api-versions.md

@@ -2,7 +2,7 @@
 [meta]: #meta
 - Name: API Versions
 - Start Date: 2019-08-05
-- CNB Pull Request: [rfcs#19](https://github.com/buildpack/rfcs/pull/19), [pack#282](https://github.com/buildpack/pack/pull/282)
+- CNB Pull Request: [rfcs#19](https://github.com/buildpacks/rfcs/pull/19), [pack#282](https://github.com/buildpacks/pack/pull/282)
 - CNB Issue: (leave blank)
 - Supersedes: N/A
 
@@ -47,4 +47,4 @@ A **missing or empty** `api` key would indicate `1.0` (the current version of th
 
 # Related RFCs
 [related-rfcs]: #related-rfcs
-[RFC: Lifecycle descriptor](https://github.com/buildpack/rfcs/pull/20)
+[RFC: Lifecycle descriptor](https://github.com/buildpacks/rfcs/pull/20)

text/0011-lifecycle-descriptor.md

@@ -2,8 +2,8 @@
 [meta]: #meta
 - Name: Lifecycle Descriptor
 - Start Date: 08/05/2019
-- CNB Pull Request: [rfcs#20](https://github.com/buildpack/rfcs/pull/20), [lifecycle#167](https://github.com/buildpack/lifecycle/pull/167), [pack#269](https://github.com/buildpack/pack/pull/269), [pack#294](https://github.com/buildpack/pack/pull/294)
-- CNB Issue: [pack#293](https://github.com/buildpack/pack/issues/293)
+- CNB Pull Request: [rfcs#20](https://github.com/buildpacks/rfcs/pull/20), [lifecycle#167](https://github.com/buildpacks/lifecycle/pull/167), [pack#269](https://github.com/buildpacks/pack/pull/269), [pack#294](https://github.com/buildpacks/pack/pull/294)
+- CNB Issue: [pack#293](https://github.com/buildpacks/pack/issues/293)
 - Supersedes: N/A
 
 # Summary

text/0012-service-binding.md

@@ -2,7 +2,7 @@
 [meta]: #meta
 - Name: Service Binding
 - Start Date: 2019-08-06
-- CNB Pull Request: [rfcs#22](https://github.com/buildpack/rfcs/pull/22), [spec#57](https://github.com/buildpack/spec/pull/57)
+- CNB Pull Request: [rfcs#22](https://github.com/buildpacks/rfcs/pull/22), [spec#57](https://github.com/buildpacks/spec/pull/57)
 - CNB Issue:
 - Supersedes: N/A
 
@@ -95,7 +95,7 @@ However, given the security improvements that secrets on the filesystem provide,
 
 Leading to this RFC, various options were considered and [even implemented][l].  The general consensus when consulting with Kubernetes and security experts is that environment variables, while easy and flexible, have fundamental issues that many organizations are unwilling to accept.  In addition de-specifying service binding was considered, but there's enough upside for cross-compatibility and a large enough percentage of buildpacks would make use of service bindings, that it was decided to create this proposal.  Not specifying service bindings, while leaving the placeholder `CNB_SERVICES` in place doesn't seem to be a real option, so if this main thrust of this proposal is not accepted `CNB_SERVICES` should be removed from the specification.
 
-[l]: https://github.com/buildpack/libbuildpack/tree/master/services
+[l]: https://github.com/buildpacks/libbuildpack/tree/master/services
 
 # Prior Art
 [prior-art]: #prior-art

text/0013-app-layer-metadata-source.md

@@ -2,7 +2,7 @@
 [meta]: #meta
 - Name: Manifest - App metadata - add source type, version and metadata
 - Start Date: 2019-06-10
-- CNB Pull Request: [rfcs#9](https://github.com/buildpack/rfcs/pull/9)
+- CNB Pull Request: [rfcs#9](https://github.com/buildpacks/rfcs/pull/9)
 - CNB Issue: (leave blank)
 - Supersedes: N/A
 
@@ -100,7 +100,7 @@ Unencoded, `io.buildpacks.app.source` is:
 The lifecycle may be provided additional metadata values, and this should be marshalled to the image manifest.
 Platforms may or may not use these additional properties.
 
-In terms of the lifecycle implementation, this is likely to require changes to the [exporter](https://github.com/buildpack/lifecycle/blob/af8b71578ed91303834ef57a7e3568ce3081f153/exporter.go#L50-L54) to add the additional app metadata.
+In terms of the lifecycle implementation, this is likely to require changes to the [exporter](https://github.com/buildpacks/lifecycle/blob/af8b71578ed91303834ef57a7e3568ce3081f153/exporter.go#L50-L54) to add the additional app metadata.
 
 # Drawbacks
 [drawbacks]: #drawbacks

text/0014-combined-restorer-analyzer-phases.md

@@ -120,7 +120,7 @@ provided (all named images will have the same layers).
 
 The `exporter` phase will be responsible for the combined activities of the
 previous `exporter` and `cacher` phases
-(see https://github.com/buildpack/spec/blob/master/buildpack.md#phase-4-export).
+(see https://github.com/buildpacks/spec/blob/master/buildpack.md#phase-4-export).
 
 The previous `/lifecycle/cacher` phase will be removed from the spec.
 
@@ -159,4 +159,3 @@ N/A
   towards flags, and away from positional args. There may be some reason
   unknown to the author as to why flag names and positional args were used
   in the first place.
-