royteeuwen opened a new pull request, #55: URL: https://github.com/apache/sling-org-apache-sling-committer-cli/pull/55
## Summary Removes all three `docker/*` actions from the publish workflow and stops the image being built twice. After this change `.github/` references only `actions/*` and `apache/*`, both implicitly trusted by the ASF allowlist — so there are no SHA pins left to maintain. ## Why remove the pins Every third-party action must appear on the ASF org-level allowlist by exact SHA. When infra approves a newer version, the previous SHA gets `expires_at` three months out and `remove_expired.yml` then deletes it automatically. A pin left past that window fails as a silent *"Startup failure"* — no logs, no notification, and the PR can look green because no checks ran. That is what ba852b8 fixed, and `docker/login-action@af1e73f9` (v4.4.0) was already scheduled to expire on **2026-10-16**. Rather than automate the bumping, all three pins turn out to be removable: * **`docker/setup-buildx-action` was never used.** `docker-maven-plugin` creates its own `docker-container` builder named `maven` and passes `--builder maven` to every buildx invocation. In run [32298804318](https://github.com/apache/sling-org-apache-sling-committer-cli/actions/runs/32298804318) the action's builder (`builder-2482bd3b-…`) was created at 20:30:00 and removed at 20:32:40 having never been targeted. buildx itself is preinstalled on the runner at `/usr/libexec/docker/cli-plugins/docker-buildx`, a system path unaffected by dmp's `docker --config` override. * **`docker/setup-qemu-action`** is replaced by the binfmt container it runs internally. Emulation is genuinely needed — the `linux/arm64` stage runs `apk add binutils`, `jlink` and `java -Xshare:dump`. Same image and tag the action defaulted to (`tonistiigi/binfmt:latest`), so the trust posture is unchanged. * **`docker/login-action`** is replaced by `docker login --password-stdin`. `AuthConfigFactory` in dmp resolves credentials from `~/.docker/config.json`, which is all the action writes. ## Why the image was built twice Run 32298804318 shows two buildx invocations against the same `maven` builder: ``` docker:build (package) buildx build --platform linux/amd64 ... --load docker:push buildx build --platform linux/amd64,linux/arm64 ... --push ``` The first image is loaded and then discarded — nothing consumes it, there is no `docker:run` or integration test against it. Adding `-Ddocker.buildArchiveOnly=true` skips it. Note it has to be `buildArchiveOnly` and **not** `docker.skip.build`. `docker:push` consumes the tar the build goal produces: ```java // BuildXService.push() File archive = new File(buildDirs.getTemporaryRootDirectory(), "docker-build.tar"); // getContextPath(archive) extracts it and passes it as --file / build context ``` `BuildMojo.executeInternal()` returns on `skipBuild` *before* `buildArchive(...)` runs, whereas `proceedWithDockerBuild()` calls `buildArchive(...)` unconditionally and only guards the buildx `--load` step behind `shallBuildArchiveOnly()`. Verified locally against docker-maven-plugin 0.48.1: | flag | `docker-build.tar` | buildx invocations | |---|---|---| | `-Ddocker.buildArchiveOnly=true` | created, 85 MB | 0 | | `-Ddocker.skip.build=true` | `tmp/` never created | 0 | ## Testing Verified locally that `mvn install -Ddocker.buildArchiveOnly=true` produces the build archive with zero buildx invocations, and that `-Ddocker.skip.build=true` produces no archive at all. **Not yet verified end-to-end.** `docker-push.yml` only triggers on push-to-master or `workflow_dispatch`, and either performs a real Docker Hub push of `apache/sling-committer-cli:latest`, so I did not trigger it from this branch. The two things a live run confirms are that dmp's builder creation works without the setup action having primed anything, and that `docker login`'s `config.json` is picked up for the push. Both are supported by the run log above, but a dispatch on this branch before merging would remove the doubt. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
