ci: publish the example images to ghcr and make them runnable - #83
Merged
Conversation
Docker Hub `livepeer/` is a curated product namespace and these are examples, so they stay out of it. The workflow defaulted to exactly that namespace whenever the repo variable was unset, so the wrong target was one cleared variable away. GHCR needs no stored credential: the built-in GITHUB_TOKEN publishes, and public packages pull anonymously, so the Docker Hub secrets go away rather than move. template-livepeer-runner and streamdiffusion-livepeer-runner already publish this way. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The previous wording said a fork PR's token cannot write packages, which is true for pull_request but not for pull_request_target, the case the same sentence names. That invites a reader to delete the `if:` that is actually doing the work. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The removed sentence restated the paragraph above it, and the registry rationale is maintainer context that already lives in the workflow header and the PR. What survives is the stale-image warning, which is the part that helps someone holding an old `rickstaa/` reference. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The images CI publishes were reachable only by hand: every compose.yml builds from source and names no image, so there was nothing for a pull to land on. Adding `image:` to the base file looked like the fix but is a trap. Compose's default pull_policy fetches a remote-resolvable image when it is missing locally, even for a service with a build section, so a plain `up -d` on a clean checkout would silently run the published image instead of the contributor's code. `pull_policy: build` avoids that but makes `docker compose pull` skip the service, losing the point. An overlay keeps the base file building from source exactly as before and reaches the registry only when asked, matching how compose.onchain already layers on. CI now parses the merged pair too. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
rickstaa
changed the title
It does not always build from source: with no `image:` key it builds once, then reuses that local image until --build. What is load-bearing is that it never reaches a registry, which is what makes the overlay the only path to the published image. Also drops the note about the frozen `rickstaa/` images. Those were never production, and it was the only thing in the repo pointing readers at a personal namespace. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The repo README carried the same "always builds from source" claim the overlay comments just lost, and the per-example notes named the image without saying how to run it, which was the original gap. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The overlay worked but cost four files, and it left the base file's worst habit intact: with no `image:` key, `up` reuses whatever it built last, so an edit is silently ignored unless you remember --build. Two interpolated fields do the same job in the file that was already there. Unset, the image name is local-only so the registry is never contacted, and `pull_policy: build` rebuilds every `up`, which the layer cache keeps near-instant and which means source edits always take. Set APP_IMAGE and APP_PULL_POLICY=always to run the published image instead. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Env vars were the smaller change but the image and the pull policy have to move together, and nothing enforced that: setting APP_IMAGE alone built from source and tagged the result as the published image, so you believed you were running the release while running your own build, and your local registry cache was poisoned with a fake `latest`. An overlay cannot be half-applied, so the switch goes back into a file. The base file keeps the part that was worth having on its own: a local-only tag it always rebuilds, so it never reaches a registry and an edit is never silently ignored. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`docker compose up --pull always` overrides `pull_policy` from the file, so the switch needs no second compose file and no env var pair that can drift apart. `--build` and `--pull always` are then a symmetric pair a reader can find in `--help`. The file keeps `pull_policy: build`, so a bare `up` still builds and never reaches a registry, and an edit is never silently ignored. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Four lines explaining two was the wrong ratio; what a reader needs is that `up` builds and that `--pull always` does not. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two lines of rationale for two lines of config; the reasoning is in the PR and the history, what a reader needs here is the two commands. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
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.
Closes #6.
Two halves: publish to GHCR instead of Docker Hub, and make the published images runnable, which they were not.
1. GHCR instead of Docker Hub
Docker Hub
livepeer/is a curated product namespace (go-livepeer,catalyst,task-runner,lpms-runner) with no examples in it, and it is staying that way, so #6's plan of moving these there is not the fix. GHCR gets thelivepeername without needing anything from the Docker Hub org, publishes with the built-inGITHUB_TOKEN, and has no anonymous pull limit.It also removes a live bug. The old metadata line read:
That default is the namespace we are being asked to stay out of, avoided today only because the repo variable happens to be set to
rickstaa.Tags, labels, the amd64-only build, and the push/dispatch allowlist are unchanged.
CI_DOCKERHUB_USERNAMEandCI_DOCKERHUB_TOKENare no longer referenced and can be deleted from repo secrets after merge.2. Running the published image
CI has published these since the workflow landed, but every
compose.ymlbuilt from source and named no image, so there was nothing a pull could land on. Two lines per example fix it:up -dup -d --buildup -d --pull always--pull alwaysoverridespull_policyfrom the file, so no second compose file and no env vars are needed, and--build/--pull alwaysare a symmetric pair a reader can find indocker compose up --help.pull_policy: buildalso fixes an existing bug on its own: today a plainup -dafter editingrunner.pysilently re-runs the previous image. The rebuild is about a second on a warm cache.Alternatives ruled out by testing
image:alone, nopull_policy. Compose pulls a remote-resolvable image when it is missing locally, even with abuildsection, so a clean checkout would silently run the published image instead of the contributor's code.APP_IMAGE/APP_PULL_POLICYenv vars. The two must move together and nothing enforces it: with the policy forgotten, compose builds from source and tags the result as the published image.docker tagthe pulled image to a local name. Works, but the tag is sticky and invisible, so every laterupkeeps using it, including after source edits.compose.image.ymloverlay. Correct, but four extra files for what one built-in flag already does.Not yet verified
An actual pull of
ghcr.io/livepeer/runner-example-*. Those packages 403 until this merges and CI publishes, so it needs one manual run afterwards, plus a check that each landed public. Visibility is a property of the package rather than the repo, and a private one looks fine to us and fails for everyone else.Note for #84
#84 adds
comfystream/compose.existing.ymlfor the same purpose.--pull alwayscovers it without the extra file.🤖 Generated with Claude Code