Skip to content

Commit cf62730

Browse files
committed
readme: key advantages
Signed-off-by: CrazyMax <1951866+crazy-max@users.noreply.github.com>
1 parent 8fc7090 commit cf62730

1 file changed

Lines changed: 103 additions & 11 deletions

File tree

README.md

Lines changed: 103 additions & 11 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,26 @@
1+
[![Test workflow](https://img.shields.io/github/actions/workflow/status/docker/github-builder-experimental/.test.yml?label=test&logo=github&style=flat-square)](https://github.com/docker/github-builder-experimental/actions?workflow=.test)
2+
13
> [!CAUTION]
24
> Do not use it for your production workflows yet!
35
4-
# GitHub Builder
6+
## :test_tube: Experimental
7+
8+
This repository is considered **EXPERIMENTAL** and under active development
9+
until further notice. It is subject to non-backward compatible changes or
10+
removal in any future version.
11+
12+
___
13+
14+
* [About](#about)
15+
* [Key Advantages](#key-advantages)
16+
* [Performance](#performance)
17+
* [Security](#security)
18+
* [Isolation & Reliability](#isolation--reliability)
19+
* [Usage](#usage)
20+
* [Build reusable workflow](#build-reusable-workflow)
21+
* [Bake reusable workflow](#bake-reusable-workflow)
22+
23+
## About
524

625
This repository provides official Docker-maintained [reusable GitHub Actions workflows](https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows)
726
to securely build container images using Docker best practices. The workflows
@@ -10,13 +29,86 @@ the principles behind [Docker Hardened Images](https://docs.docker.com/dhi/),
1029
enabling open source projects to follow a seamless path toward higher levels of
1130
security and trust.
1231

13-
## :test_tube: Experimental
14-
15-
This repository is considered **EXPERIMENTAL** and under active development
16-
until further notice. It is subject to non-backward compatible changes or
17-
removal in any future version.
18-
19-
## Build reusable workflow
32+
## Key Advantages
33+
34+
### Performance
35+
36+
* **Native parallelization for multi-platform builds.**
37+
Workflows automatically distribute builds across runners based on target
38+
platform to be built, improving throughput for other architectures without
39+
requiring emulation or [custom CI logic](https://docs.docker.com/build/ci/github-actions/multi-platform/#distribute-build-across-multiple-runners)
40+
or self-managed runners.
41+
42+
* **Optimized cache warming & reuse.**
43+
The builder uses the [GitHub Actions cache backend](https://docs.docker.com/build/cache/backends/gha/)
44+
to persist layers across branches, PRs, and rebuilds. This significantly
45+
reduces cold-start times and avoids repeating expensive dependency
46+
installations, even for external contributors' pull requests.
47+
48+
* **Centralized build configuration.**
49+
Repositories no longer need to configure buildx drivers, tune storage, or
50+
adjust resource limits. The reusable workflows encapsulate the recommended
51+
configuration, providing fast, consistent builds across any project that
52+
opts in.
53+
54+
### Security
55+
56+
* **Trusted workflows in the Docker organization.**
57+
Builds are executed by reusable workflows defined in the [**@docker**](https://github.com/docker)
58+
organization, not by arbitrary user-defined workflow steps. Consumers can
59+
rely on GitHub's trust model and repository protections on the Docker side
60+
(branch protection, code review, signing, etc.) to reason about who controls
61+
the build logic.
62+
63+
* **Verifiable, immutable sources.**
64+
The workflows use the GitHub OIDC token and the exact commit SHA to obtain
65+
source and to bind it into SLSA provenance. This ensures that the build is
66+
tied to the repository contents as checked in—no additional CI step can
67+
silently swap out what is being built.
68+
69+
* **Signed SLSA provenance for every build.**
70+
BuildKit generates [SLSA-compliant provenance attestation](https://docs.docker.com/build/metadata/attestations/slsa-provenance/)
71+
artifacts that are signed with an identity bound to the GitHub workflow.
72+
Downstream consumers can verify:
73+
- which commit produced the image
74+
- which workflow and job executed the build
75+
- what inputs and build parameters were used
76+
77+
* **Protection from user workflow tampering.**
78+
The user workflow never executes `docker build` directly. Instead, it calls
79+
a reusable workflow owned by the [**@docker**](https://github.com/docker)
80+
organization. This prevents untrusted workflow steps in the user repository
81+
from modifying the build logic, injecting unexpected flags, or producing
82+
misleading provenance.
83+
84+
### Isolation & Reliability
85+
86+
* **Separation between user CI logic and build logic.**
87+
The user's workflow orchestrates *when* to build but not *how* to build.
88+
The actual build steps live in the Docker-maintained reusable workflows,
89+
which cannot be modified from the consuming repository.
90+
91+
* **Immutable, reproducible build pipeline.**
92+
Builds are driven by declarative inputs (repository commit, build
93+
configuration, workflow version). This leads to:
94+
- reproducibility (same workflow + same inputs → same outputs)
95+
- auditability (inputs and workflow identity recorded in provenance)
96+
- reliability (less dependence on ad-hoc per-repo CI scripting)
97+
98+
* **Reduced CI variability and config drift.**
99+
By reusing the same workflows, projects avoid maintaining custom build logic
100+
per repository. Caching, provenance, SBOM generation, and build settings
101+
behave uniformly across all adopters.
102+
103+
* **Higher assurance for downstream consumers.**
104+
Because artifacts are produced by a workflow in the [**@docker**](https://github.com/docker)
105+
organization, with SLSA provenance attached, consumers can verify both the
106+
*source commit* and the *builder identity* before trusting or promoting an
107+
image—an essential part of supply-chain hardening.
108+
109+
## Usage
110+
111+
### Build reusable workflow
20112

21113
```yaml
22114
name: ci
@@ -36,7 +128,7 @@ on:
36128
uses: docker/github-builder-experimental/.github/workflows/build.yml@main
37129
permissions:
38130
contents: read # to fetch the repository content
39-
id-token: write # for signing attestation manifests with GitHub OIDC Token
131+
id-token: write # for signing attestation(s) with GitHub OIDC Token
40132
with:
41133
output: image
42134
push: ${{ github.event_name != 'pull_request' }}
@@ -71,7 +163,7 @@ on:
71163
72164
You can find the list of available inputs in [`.github/workflows/build.yml`](.github/workflows/build.yml).
73165

74-
## Bake reusable workflow
166+
### Bake reusable workflow
75167

76168
```yaml
77169
name: ci
@@ -91,7 +183,7 @@ on:
91183
uses: docker/github-builder-experimental/.github/workflows/bake.yml@main
92184
permissions:
93185
contents: read # to fetch the repository content
94-
id-token: write # for signing attestation manifests with GitHub OIDC Token
186+
id-token: write # for signing attestation(s) with GitHub OIDC Token
95187
with:
96188
output: image
97189
push: ${{ github.event_name != 'pull_request' }}

0 commit comments

Comments
 (0)