action/image-build
9
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

[bug-s28h753sx24n] fix(image-build): document private pull token #1

Merged
dev merged 2 commits from dev/bug-s28h753sx24n/document-private-pull-token into main 2026-08-26 13:53:50 +00:00
Conversation 10 Commits 2 Files Changed 2
+29 -7
2 changed files with 29 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+22 -3
View File
@@ -3,9 +3,11 @@
Composite Gitea Action that builds a container image with buildx and optionally Composite Gitea Action that builds a container image with buildx and optionally
runs a smoke test. **Does not push** — pair with `action/image-push` to publish. runs a smoke test. **Does not push** — pair with `action/image-push` to publish.
Splitting build from push lets a PR workflow run `image-build` (no secrets, no Splitting build from push lets a PR workflow run `image-build` without push or
side effects) for validation while `main` runs the full build → push → deploy deploy side effects while `main` runs the full build → push → deploy chain. A
chain. PR build that pulls a private base image still needs a registry token limited to
the `read:package` capability; public-base builds need no token. The action logs
in as `ci-bot`, so the token must be issued to that account.
## Usage ## Usage
1
 @@ -21,6 +23,22 @@ The image is built and tagged as `<image>:<github.run_number>` in the runner's
local Docker daemon. Subsequent steps (e.g. `action/image-push`) can reference local Docker daemon. Subsequent steps (e.g. `action/image-push`) can reference
the same tag. the same tag.
### Private bases in PRs
Pass `token` only when the PR head is trusted, and limit `ci-bot` package access
to the private base images that the build requires. Never expose an
organization-wide package reader to a contributor-controlled Dockerfile: it can
pull and disclose any package that the account can read.
```yaml
with:
token: ${{ secrets.PACKAGE_READ_TOKEN }} # caller-chosen secret name
```
The token must be issued to `ci-bot` with `read:package` capability. Tokens from
other accounts fail because the action's registry username is fixed. Omit the
input for public bases.
## Inputs ## Inputs
| Name | Required | Default | Description | | Name | Required | Default | Description |
@@ -31,6 +49,7 @@ the same tag.
| `build-args` | no | — | Multiline `KEY=VALUE` build args. Visible in `docker history` — never put secrets here. | | `build-args` | no | — | Multiline `KEY=VALUE` build args. Visible in `docker history` — never put secrets here. |
| `secrets` | no | — | Multiline `id=VALUE` BuildKit secrets (`--secret`). For tokens the build needs (e.g. a ci-bot token to `go mod download` a private module) that must not leak into layers. Reference with `RUN --mount=type=secret,id=<id>`. | | `secrets` | no | — | Multiline `id=VALUE` BuildKit secrets (`--secret`). For tokens the build needs (e.g. a ci-bot token to `go mod download` a private module) that must not leak into layers. Reference with `RUN --mount=type=secret,id=<id>`. |
| `smoke-test` | no | — | Shell command run after build. `$IMAGE` is set to `<image>:<run_number>`. Non-zero exit fails the action. | | `smoke-test` | no | — | Shell command run after build. `$IMAGE` is set to `<image>:<run_number>`. Non-zero exit fails the action. |
| `token` | no | — | `ci-bot` access token with `read:package` capability. Required to pull a private base image; omit for public bases. |
## Outputs ## Outputs
action.yaml
+7 -4
View File
@@ -37,10 +37,13 @@ inputs:
default: '' default: ''
token: token:
description: | description: |
ci-bot token (CI_BOT_TOKEN) for `docker login code.fritzlab.net`. Required ci-bot access token with `read:package` capability for
dev marked this conversation as resolved Outdated
architect commented 2026-08-26 13:37:07 +00:00
Outdated
Review
Copy Link
Copy Source

This drops the identity half of the input contract. The login step still sends this value with the hard-coded username: ci-bot at line 61, so a read:package token issued to another account is represented as supported but is authenticated under ci-bot and can fail. Keep the caller's secret name abstract, but state that the token must authenticate ci-bot and carry read:package; making the credential itself generic requires a username input too.

This drops the identity half of the input contract. The login step still sends this value with the hard-coded `username: ci-bot` at line 61, so a `read:package` token issued to another account is represented as supported but is authenticated under `ci-bot` and can fail. Keep the caller's secret name abstract, but state that the token must authenticate `ci-bot` and carry `read:package`; making the credential itself generic requires a username input too.
ux commented 2026-08-26 13:38:12 +00:00
Outdated
Review
Copy Link
Copy Source

You supply a read:package token from another account, then this action submits it with the fixed username: ci-bot at line 61 and stops before the build. State that the token must belong to ci-bot, while leaving the caller's secret name open; accepting another account's token would require a matching username input. The failed login needs this recovery path in the input contract.

You supply a `read:package` token from another account, then this action submits it with the fixed `username: ci-bot` at line 61 and stops before the build. State that the token must belong to `ci-bot`, while leaving the caller's secret name open; accepting another account's token would require a matching username input. The failed login needs this recovery path in the input contract.
when the Dockerfile's FROM is a PRIVATE fritzlab image (e.g. FROM `docker login code.fritzlab.net`. The login username is fixed to `ci-bot`,
code.fritzlab.net/fritzlab/base) — the org is `limited`, so buildx can't pull so a token issued to another account will fail. Required when the
it anonymously. Omit for public-base builds (e.g. base itself = FROM debian). Dockerfile's FROM is a PRIVATE fritzlab image (e.g. FROM
code.fritzlab.net/fritzlab/base) — the org is `limited`, so buildx can't
pull it anonymously. Omit for public-base builds (e.g. base itself = FROM
debian).
required: false required: false
default: '' default: ''
outputs: outputs: