Skip to content

Commit

Permalink
Backout accidental changes to specs besides platform
Browse files Browse the repository at this point in the history
Signed-off-by: Emily Casey <ecasey@vmware.com>
  • Loading branch information
ekcasey committed Jul 15, 2020
1 parent 1f95293 commit 7cf284f
Show file tree
Hide file tree
Showing 4 changed files with 248 additions and 46 deletions.
82 changes: 55 additions & 27 deletions buildpack.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,31 +15,59 @@ The `ENTRYPOINT` of the OCI image contains logic implemented by the lifecycle th

## Table of Contents

1. [Buildpack Interface](#buildpack-interface)
1. [Key](#key)
2. [Detection](#detection)
3. [Build](#build)
4. [Layer Types](#layer-types)
2. [App Interface](#app-interface)
3. [Phase #1: Detection](#phase-1-detection)
4. [Phase #2: Analysis](#phase-2-analysis)
5. [Phase #3: Build](#phase-3-build)
6. [Phase #4: Export](#phase-4-export)
7. [Launch](#launch)
8. [Environment](#environment)
1. [Provided by the Lifecycle](#provided-by-the-lifecycle)
2. [Provided by the Platform](#provided-by-the-platform)
3. [Provided by the Buildpacks](#provided-by-the-buildpacks)
9. [Security Considerations](#security-considerations)
1. [Assumptions of Trust](#assumptions-of-trust)
2. [Requirements](#requirements)
10. [Data Format](#data-format)
1. [launch.toml (TOML)](#launchtoml-toml)
2. [Build Plan (TOML)](#build-plan-toml)
3. [Buildpack Plan (TOML)](#buildpack-plan-toml)
4. [Bill-of-Materials (TOML)](#bill-of-materials-toml)
5. [Layer Content Metadata (TOML)](#layer-content-metadata-toml)
6. [buildpack.toml (TOML)](#buildpacktoml-toml)
- [Buildpack Interface Specification](#buildpack-interface-specification)
- [Table of Contents](#table-of-contents)
- [Buildpack Interface](#buildpack-interface)
- [Key](#key)
- [Detection](#detection)
- [Build](#build)
- [Layer Types](#layer-types)
- [Launch Layers](#launch-layers)
- [Build Layers](#build-layers)
- [Other Layers](#other-layers)
- [App Interface](#app-interface)
- [Phase #1: Detection](#phase-1-detection)
- [Purpose](#purpose)
- [Process](#process)
- [Order Resolution](#order-resolution)
- [Phase #2: Analysis](#phase-2-analysis)
- [Purpose](#purpose-1)
- [Process](#process-1)
- [Phase #3: Build](#phase-3-build)
- [Purpose](#purpose-2)
- [Process](#process-2)
- [Buildpack Plan Entry Refinements](#buildpack-plan-entry-refinements)
- [Layers](#layers)
- [Phase #4: Export](#phase-4-export)
- [Purpose](#purpose-3)
- [Process](#process-3)
- [Launch](#launch)
- [Purpose](#purpose-4)
- [Process](#process-4)
- [Environment](#environment)
- [Provided by the Lifecycle](#provided-by-the-lifecycle)
- [Layer Paths](#layer-paths)
- [Provided by the Platform](#provided-by-the-platform)
- [Provided by the Buildpacks](#provided-by-the-buildpacks)
- [Environment Variable Modification Rules](#environment-variable-modification-rules)
- [Delimiter](#delimiter)
- [Prepend](#prepend)
- [Append](#append)
- [Override](#override)
- [Default](#default)
- [Security Considerations](#security-considerations)
- [Assumptions of Trust](#assumptions-of-trust)
- [Requirements](#requirements)
- [Data Format](#data-format)
- [launch.toml (TOML)](#launchtoml-toml)
- [store.toml (TOML)](#storetoml-toml)
- [Build Plan (TOML)](#build-plan-toml)
- [Buildpack Plan (TOML)](#buildpack-plan-toml)
- [Bill-of-Materials (TOML)](#bill-of-materials-toml)
- [Layer Content Metadata (TOML)](#layer-content-metadata-toml)
- [buildpack.toml (TOML)](#buildpacktoml-toml)
- [Buildpack Implementations](#buildpack-implementations)
- [Order Buildpacks](#order-buildpacks)

## Buildpack Interface

Expand Down Expand Up @@ -93,8 +121,8 @@ Executable: `/bin/build <layers[EIC]> <platform[AR]> <plan[E]>`, Working Dir: `<
| `/dev/stdout` | Logs (info)
| `/dev/stderr` | Logs (warnings, errors)
| `<plan>` | Refinements to the [Buildpack Plan](#buildpack-plan-toml) (TOML)
| `<layers>/launch.toml` | App metadata (see [launch.toml](#launch.toml-toml))
| `<layers>/store.toml` | Persistent metadata (see [store.toml](#store.toml-toml))
| `<layers>/launch.toml` | App metadata (see [launch.toml](#launchtoml-toml))
| `<layers>/store.toml` | Persistent metadata (see [store.toml](#storetoml-toml))
| `<layers>/<layer>.toml` | Layer metadata (see [Layer Content Metadata](#layer-content-metadata-toml))
| `<layers>/<layer>/bin/` | Binaries for launch and/or subsequent buildpacks
| `<layers>/<layer>/lib/` | Shared libraries for launch and/or subsequent buildpacks
Expand Down
12 changes: 6 additions & 6 deletions distribution.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,11 +5,11 @@ This document specifies the artifact format, delivery mechanism, and order resol

## Table of Contents

1. [Order Resolution](#order-resolution)
2. [Artifact Format](#artifact-format)
1. [Buildpack](#buildpack)
2. [Buildpackage](#buildpackage)

- [Distribution Specification](#distribution-specification)
- [Table of Contents](#table-of-contents)
- [Artifact Format](#artifact-format)
- [Buildpack](#buildpack)
- [Buildpackage](#buildpackage)

## Artifact Format

Expand Down Expand Up @@ -54,4 +54,4 @@ For each listed stack, all associated buildpacks MUST be a candidate for detecti
Each stack ID MUST only be present once.
For a given stack, the `mixins` list MUST enumerate mixins such that no included buildpacks are missing a mixin for the stack.

Fewer stack entries as well as additional mixins for a stack entry MAY be specified.
Fewer stack entries as well as additional mixins for a stack entry MAY be specified.
44 changes: 31 additions & 13 deletions extensions/bindings.md
Original file line number Diff line number Diff line change
@@ -1,11 +1,27 @@
# Bindings
Bindings are exposed inside of a container during all three phases of the lifecycle; detect, build, and launch. The contents of bindings MUST NOT be part of the image created after the detect and build phases.

Bindings are exposed inside of a container during the detect, build, and launch phases of the lifecycle. The contents of bindings MUST NOT be part of the image created after the detect and build phases.

## Table of Contents

- [Bindings](#bindings)
- [Table of Contents](#table-of-contents)
- [Detect and Build Phases](#detect-and-build-phases)
- [Metadata](#metadata)
- [Secret](#secret)
- [Example Directory Structure](#example-directory-structure)
- [Launch Phase](#launch-phase)
- [Metadata](#metadata-1)
- [Secret](#secret-1)
- [Example Directory Structure](#example-directory-structure-1)

## Detect and Build Phases
During the detect and build phases, the lifecycle MUST provide any bindings as files in `<platform>/bindings/<binding-name>` with directory names matching the name of the binding. Binding names MUST match `[a-z0-9\-\.]{1,253}`.

Before initiating the detect or build phases on the build-image, the platform MUST provide any bindings as files in `<platform>/bindings/<binding-name>` with directory names matching the name of the binding. Binding names MUST match `[a-z0-9\-\.]{1,253}`.

### Metadata
Within each binding directory the lifecycle MUST provide a `metadata` directory containing `kind`, `provider`, and `tags` files. The value of the `kind` file MUST contain an abstract classification of the binding. The value of the `provider` file MUST identify the provider of this binding. The value of the `tags` file MUST contain a newline delimited collection of tags attached to the binding.

Within each binding directory the platform MUST provide a `metadata` directory containing `kind` and `provider` files. The value of the `kind` file MUST contain an abstract classification of the binding. The value of the `provider` file MUST identify the provider of this binding.

In addition to the required files, the `metadata` directory MAY contain additional metadata about the binding with file names and contents matching the metadata names and contents.

Expand All @@ -14,7 +30,8 @@ The collection of files within the directory MAY change between detect and build
The contents of the files MAY change between detect and build phase pairs. The contents of the files MUST NOT change during the detect and build phase pair.

### Secret
Within each binding directory the lifecycle MAY provide a `secret` directory containing the secret associated with the binding with filenames matching the secret key names.

Within each binding directory the platform MAY provide a `secret` directory containing the secret associated with the binding with filenames matching the secret key names.

During the detect and build phases, if the `secret` directory exists, the contents of the files MAY be one of the following:

Expand All @@ -27,32 +44,33 @@ If the `secret` directory exists, the contents of the files MAY change between d


### Example Directory Structure

```plain
<platform>
└── bindings
├── primary-db
│ └── metadata
│ ├── connection-count
│ ├── kind
│ ├── provider
│ └── tags
│ └── provider
└── secondary-db
├── metadata
│ ├── connection-count
│ ├── kind
│ ├── provider
│ └── tags
│ └── provider
└── secret
├── endpoint
├── password
└── username
```

## Launch Phase
During the launch phase, the lifecycle MUST provide any bindings as files in `$CNB_BINDINGS/<binding-name>` with directory names matching the name of the binding. Binding names MUST match `[a-z0-9\-\.]{1,253}`. The `CNB_BINDINGS` environment variable MUST be declared and can point to any valid filesystem location.

During the launch phase, the platform MUST provide any bindings as files in `$CNB_BINDINGS/<binding-name>` with directory names matching the name of the binding. Binding names MUST match `[a-z0-9\-\.]{1,253}`. The `CNB_BINDINGS` environment variable MUST be declared and can point to any valid filesystem location.

### Metadata
Within each binding directory the lifecycle MUST provide a `metadata` directory containing `kind`, `provider`, and `tags` files. The value of the `kind` file MUST contain an abstract classification of the binding. The value of the `provider` file MUST identify the provider of this binding. The value of the `tags` file MUST contain a newline delimited collection of tags attached to the binding.

Within each binding directory the platform MUST provide a `metadata` directory containing `kind` and `provider` files. The value of the `kind` file MUST contain an abstract classification of the binding. The value of the `provider` file MUST identify the provider of this binding.

In addition to the required files, the `metadata` directory MAY contain additional metadata about the binding with file names and contents matching the metadata names and contents.

Expand All @@ -61,7 +79,8 @@ The collection of files within the directory MAY change between launches. The c
The contents of the files MAY change between launches. The contents of the files MAY change during the launch phase.

### Secret
Within each binding directory the lifecycle MUST provide a `secret` directory containing the secret associated with the binding with filenames matching the secret key names.

Within each binding directory the platform MUST provide a `secret` directory containing the secret associated with the binding with filenames matching the secret key names.

During the launch phase, the contents of the files MAY be one of the following:

Expand All @@ -73,14 +92,14 @@ The collection of files within the directory MAY change between launches. The c
The contents of the files MAY change between launches. The contents of the files MAY change during the launch phase.

### Example Directory Structure

```plain
custom-bindings-location
├── primary-db
│ ├── metadata
│ │ ├── connection-count
│ │ ├── kind
│ │ ├── provider
│ │ └── tags
│ └── secret
│ ├── endpoint
│ ├── password
Expand All @@ -90,7 +109,6 @@ custom-bindings-location
│ ├── connection-count
│ ├── kind
│ ├── provider
│ └── tags
└── secret
├── endpoint
├── password
Expand Down
156 changes: 156 additions & 0 deletions extensions/project-descriptor.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,156 @@
# Project Descriptor

A project descriptor is a file that MAY contain configuration for apps, services, functions, and buildpacks. By default, the file SHOULD be named `project.toml` and located in the root directory of a project's repository. A platform SHOULD read the file to enrich the build process.

## Schema

The TOML schema of the project descriptor is the following:

```toml
[project]
id = "<string>" # machine readble
name = "<string>" # human readable
version = "<string>"
authors = ["<string>"]
documentation-url = "<url>"
source-url = "<url>"

[[project.licenses]]
type = "<string>"
uri = "<uri>"

[build]
include = ["<string>"]
exclude = ["<string>"]
[[build.buildpacks]]
id = "<string>"
version = "<string>"
uri = "<string>"
[[build.env]]
name = "<string>"
value = "<string>"
[metadata]
# additional arbitrary keys allowed
```

The following sections describe each part of the schema in detail.

## `[project]`

The top-level `[project]` table MAY contain configuration about the repository, including `id` and `version`. It MAY also include metadata about how it is authored, documented, and version controlled.

The `project.id`

```toml
[project]
id = "<string>"
name = "<string>"
version = "<string>"
```

* `id` - (optional) the machine readable identifier of the project (ex. "com.example.myservice")
* `name` - (optional) the human readable name of the project (ex. "My Example Service")
* `version` - (optional) and arbitrary string representing the version of the project
* `authors` - (optional) the names and/or email addresses of the project's authors
* `documentation-url` - (optional) a URL to the documentation for the project
* `source-url` - (optional) a URL to the source code for the project

## `[[project.licenses]]`

An optional list of project licenses.

* `type` - This MAY use the [SPDX 2.1 license expression](https://spdx.org/spdx-specification-21-web-version), but is not limited to identifiers in the [SPDX Licenses List](https://spdx.org/licenses/).
* `uri` - If this project is using a nonstandard license, then this key MAY be specified in lieu of or in addition to `type` to point to the license.

## `[build.include]` and `[build.exclude]`

A optional list of files to include in the build (while excluding everything else):

```toml
[build]
include = [
"cmd/",
"go.mod",
"go.sum",
"*.go"
]
```

A list of files to exclude from the build (while including everything else):

```toml
[build]
exclude = [
"spec/"
]
```

The `.gitignore` pattern is used in both cases. The `exclude` and `include` keys are mutually exclusive, and if both are present the Lifecycle will error out.

Any files that are excluded (either via `include` or `exclude`) MUST BE excluded before the build (i.e. not only exluded from the final image).

If both `exclude` and `include` are defined, the build process MUST result in an error.

## `[[build.buildpacks]]`

The build table MAY contain an array of buildpacks. The schema for this table is:

```toml
[[build.buildpacks]]
id = "<buildpack ID (optional)>"
version = "<buildpack version (optional default=latest)>"
uri = "<url or path to the buildpack (optional default=urn:buildpack:<id>)"
```

This defines the buildpacks that a platform should use on the repo.

Either an `id` or a `uri` MUST be included, but MUST NOT include both. If `uri` is provided, `version` MUST NOT be allowed.

## `[[build.env]]`

Used to set environment variables at build time, for example:

```toml
[[build.env]]
name = "JAVA_OPTS"
value = "-Xmx1g"
```

## `[metadata]`

This table includes a some defined keys, but additional keys are not validated. It can be used to add platform specific metadata. For example:

```toml
[metadata.heroku]
pipeline = "foobar"
```

## Example

```toml
[project]
id = "io.buildpacks.my-app"
version = "0.1"

[build]
include = [
"cmd/",
"go.mod",
"go.sum",
"*.go"
]

[[build.buildpacks]]
id = "io.buildpacks/java"
version = "1.0"

[[build.buildpacks]]
id = "io.buildpacks/nodejs"
version = "1.0"

[metadata]
foo = "bar"

[metadata.fizz]
buzz = ["a", "b", "c"]
```

0 comments on commit 7cf284f

Please sign in to comment.