chore(plugin-oci): drop the per-target progress logs - #384
Open
raphaelvigee wants to merge 1 commit into
Open
Conversation
Six `info!` lines saying a driver had done the thing it exists to do: `oci_pull: pulled`, `oci_push: pushed`, `oci_load: loaded`, `oci_image: assembled`, `oci_layer: packed`, `oci_index: grouped`. The engine already reports which targets ran and how long they took, so one line per target per driver restates it in a second, less structured place — and scales with the graph, which is the wrong direction for a build of a few hundred images. The two `warn!`s stay. They report something the engine cannot: that an `oci_pull` ref is an unpinned tag and therefore not reproducible, and that a target's `log.txt` could not be opened. Both are diagnostics, not progress. The `debug!` about anonymous registry credentials stays too. `oci_push` no longer binds the digest `push_layout` returns, and the cdylib's log-sink doc cited two of the removed lines as the reason the sink exists; it now names the diagnostics that actually depend on it. One consequence worth stating: `oci_load`'s line was the only place the derived `<repo>:<hashin>` tag was surfaced. Anything that needs it now has to compute it, or the tag has to be exposed as an output group — noted on the PR rather than decided here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01WqQZxsTqanJRWLWdPSchBo
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Top of stack #379: #159 → #378 → #381 → #383 → this.
What
Six
info!lines saying a driver did the thing it exists to do:oci_pulloci_pull: pulledoci_pushoci_push: pushedoci_loadoci_load: loadedoci_imageoci_image: assembledoci_layeroci_layer: packedoci_indexoci_index: groupedAll removed. The engine already reports which targets ran and how long they took, so these restate it in a second, less structured place — and they scale with the graph, which is the wrong direction for a build with a few hundred images.
What stays
The two
warn!s, because they say something the engine cannot:oci_pullon an unpinned tag — the ref string is the cache key, so a moved tag serves a stale archive. Not progress; a correctness caveat.log.txtfailing to open — an error path.Plus the
debug!about falling back to anonymous registry credentials, which is what an unexpected 401 gets diagnosed from.Fallout
oci_pushno longer binds the digestpush_layoutreturns.docker_build built/oci_push: pushedas the reason the sink exists. It now names the diagnostics that actually depend on it, since the lines it pointed at are gone.One thing to decide
oci_load's line was the only place the derived<repo>:<hashin>tag was surfaced. With it gone, anything that wants to know what todocker runhas to recompute the name and readhashinout ofheph inspect.That is a real loss and it is not obviously the right trade. The clean fix is to expose the tag as an output group, the way
oci_imageexposesdigest— a downstream target could then read it directly, which is better than a log line was. I have not done it here:oci_loadis an uncached action with no outputs today, so adding one is a design change rather than a cleanup, and it belongs in its own PR.Say the word and I will add it; otherwise this ships as-is.
🤖 Generated with Claude Code
https://claude.ai/code/session_01WqQZxsTqanJRWLWdPSchBo