Docs: Add Docker workflows design brief

[ModeSevenIndustrialSolutions]

Docs: Add Docker workflows design brief

Replaces the workflows-template placeholder brief with the research/gap-analysis brief for the Docker build/publish workflows.

Tracking issue: lfreleng-actions/.github#142

Contents

• ONAP Docker landscape census — 306 Dockerfiles across 99 repos (vs the 23 the reporting tool classifies — root-level-only detection caveat documented); fabric8 docker-maven-plugin dominant (63 repos), plus Spotify-plugin/shell/Gradle/jib minorities
• Conventions — version.properties (110 repos), SNAPSHOT/STAGING tag idioms, releases/*-container.yaml self-release files (1,286 across the estate), Nexus3 registry port topology
• Layout matrix the workflows must handle — single-image, Maven-module, multi-image monorepos, base-image chains, artifact-first builds, multi-arch
• Priority order from the release-mapping tool (57 repos shipping 88 in-release images; base-image repos first, sdc/sdc-docker-base as pilot)
• Reuse analysis — existing lfreleng action estate + third-party Docker actions (buy-don't-build conclusion)
• Gap list — proposed workflow lanes (build-test / merge Model B / build-test-release Model A), input surface, new actions needed (docker-build-matrix-action, docker-promote-action), fixture gaps
• Rollout plan and open questions

Linting

• Tables normalised with markdown-table-fixer; markdownlint passes
• docs/BRIEF.md retains the template's existing write-good exemption (design-decisions record, not polished prose)
• All other pre-commit hooks pass (reuse, codespell, etc.)

The brief is the input for the subsequent agentic development rounds that will implement the workflows and supporting actions.

[Copilot]

Pull request overview

Updates docs/BRIEF.md to replace the template placeholder with a detailed design brief / gap analysis that will guide the upcoming implementation of reusable Docker build/publish workflows (including ONAP-specific constraints and rollout sequencing).

Changes:

• Replaces the generic workflows-template brief with a Docker workflows gap-analysis brief (ONAP census, conventions, layouts, and priority order).
• Documents proposed workflow lanes (verify / Model A / Model B), input surface, reuse vs build decisions, and action/fixture gaps.
• Adds rollout plan and open questions to drive subsequent implementation rounds.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (1)

docs/BRIEF.md:130

• This paragraph asserts the registry endpoints are already in the org harden-runner allow-list at “v0.12.1”, but the workflows in this repo currently default harden_runner_allowlist to a v0.4.1 pin. To avoid misleading readers, either align the version reference with the workflow default, or rephrase as a requirement (and note the pin to bump when enabling block mode).

All of these endpoints (Docker Hub auth/registry/CDN hosts, `ghcr.io`,
`hub.docker.com`, `nexus3.onap.org:10001-10004`) are **already in the
org harden-runner `allow_list.txt` (v0.12.1)**. Base images pulled
from arbitrary third-party registries are the un-enumerable case —

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

Suppressed comments (1)

docs/BRIEF.md:132

• This paragraph cites org harden-runner allow_list.txt v0.12.1, but this repository’s workflow defaults currently pin the allow-list at v0.4.1 (e.g. .github/workflows/build-test.yaml). As written, the doc can mislead readers into assuming the pinned allow-list already includes these endpoints; either align the version reference with the pinned default or call out that the pin must be bumped.

All of these endpoints (Docker Hub auth/registry/CDN hosts, `ghcr.io`,
`hub.docker.com`, `nexus3.onap.org:10001-10004`) are **already in the
org harden-runner `allow_list.txt` (v0.12.1)**. Base images pulled
from arbitrary third-party registries are the un-enumerable case —
exactly what the `build_permit_egress_traffic` hatch (already in the