Repository navigation
Conversation
GitHub Actions examples lead with individual actions despite the reusable build workflows. Present Builder first for supported recipes, explain its defaults, and retain action-based alternatives for tasks that need them.
✅ Deploy Preview for docsdocker ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
github-actions
Bot
added
the
area/build
The separate Builder subsection duplicates the preferred introduction and action comparison. Move its build, Bake, and architecture guides into the main GitHub Actions section, consolidate the overview, and preserve old page URLs and fragments.
Standalone Builder references obscure the name of Docker GitHub Builder. Use GitHub Builder in prose, headings, and navigation while preserving existing heading anchors.
Separate HTML anchors duplicate the role of explicit heading IDs. Attach the existing fragment IDs to the workflow headings using Markdown attributes.
The GitHub Actions introduction repeats recipe navigation in an Examples section. Remove that section and its sectionlinks list while retaining the task links in the introduction.
Removing the GitHub Actions recipe list left its shortcode unused, causing strict Hugo builds to fail. Remove the unreferenced template so validation can build the site.
|
bump here @docker/docs-team @crazy-max |
Ah forgot to review, will take a look today |
crazy-max
left a comment
crazy-max
left a comment
There was a problem hiding this comment.
Non-blocking, pre-existing drift in the moved guides: build-workflow.md:62–63 and github-builder-architecture/index.md:52–58 describe the default runners as ubuntu-24.04 and ubuntu-24.04-arm, but the referenced Builder v1 uses ubuntu-26.04 and ubuntu-26.04-arm.
Update the descriptions of the defaults to match upstream, or link to the workflow's runner defaults to avoid duplicating values that can change: https://github.com/docker/github-builder#runner-mapping
Explicit examples using 24.04 can stay if they aren't presented as defaults. This can be handled in a follow-up.
| set-meta-annotations: true | ||
| annotations: | | ||
| index:org.opencontainers.image.description=My application |
There was a problem hiding this comment.
With set-meta-annotations: true, the generated repository description overwrites My application in the final index. Builder appends generated annotations after explicit ones and converts both to index annotations, where the last value wins.
Pass the custom description through meta-annotations instead so it overrides the generated default while preserving the other metadata:
| set-meta-annotations: true | |
| annotations: | | |
| index:org.opencontainers.image.description=My application | |
| set-meta-annotations: true | |
| meta-annotations: | | |
| org.opencontainers.image.description=My application |
| GitHub Builder checks out the repository for the triggering event in its own jobs. | ||
| Files changed in a caller job aren't automatically available to the build. |
There was a problem hiding this comment.
Small wording correction: build.yml uses a Git context rather than checking out the repository on the runner. "Aren't automatically available" also suggests caller-job changes could be included through extra configuration.
| GitHub Builder checks out the repository for the triggering event in its own jobs. | |
| Files changed in a caller job aren't automatically available to the build. | |
| GitHub Builder builds from the repository at the triggering Git reference. | |
| Files changed in a caller job aren't included in the build. |
The annotation example could overwrite its custom description, and the introduction described a checkout instead of a Git context. Use metadata overrides, clarify which files are built, and link to upstream runner defaults to avoid duplicating changing values.
Present Docker GitHub Builder first in the GitHub Actions introduction, multi-platform guide, and supported task recipes. Keep individual-action alternatives for local images, custom builders, and workflows that need steps on the same runner. Explain differences in metadata, cache, permissions, signing, and secrets.
Validation: scoped rumdl and Vale checks, 13 reusable calls checked against the recorded upstream contract, a full Hugo build, and 234 rendered internal links and fragments checked. GitHub workflows were not run.