CI: publish the :dev image from main pushes - #200
Merged
Brandon-Haney merged 1 commit intoJul 29, 2026
Conversation
The publish job gates on a push to `dev`, but that branch doesn't exist in this repo, so the only trigger that ever fires is a published release. Merged work has no image until the next release is cut, which leaves nothing for users to test a fix against and no way to confirm one before it ships. Adds `main` alongside `dev` on both the job condition and the `:dev` tag rule, so every merge publishes a rolling `ghcr.io/<owner>/plexcache-d:dev`. Release behaviour is unchanged. Semver tags and `:latest` remain release-only, so a merge to main cannot move the stable tag: merge to main -> :dev push to dev -> :dev (unchanged) full release -> semver, :latest (unchanged) prerelease -> semver (unchanged) PR / v3.0 push -> no publish (unchanged)
Collaborator
Author
|
@StudioNirin review these when you are available, thanks |
StudioNirin
approved these changes
Jul 29, 2026
Brandon-Haney
added a commit
that referenced
this pull request
Jul 30, 2026
Two fixes to the image publishing workflow, both surfaced while bringing the rolling :dev channel online in #200. Docker v2 manifests. Images are pushed with OCI media types, and Unraid's update check requests only Docker media types, so the registry returns 404 for the manifest and the container reports "not available" rather than an update status. Verified against the registry with Docker-only Accept headers: studionirin/plexcache-d:dev -> 404 (application/vnd.oci.image.manifest.v1+json) studionirin/plexcache-d:latest -> 200 (application/vnd.docker.distribution.manifest.v2+json) `provenance: false` was already set and isn't sufficient on its own, so this also disables SBOM attestation and sets oci-mediatypes=false via the image exporter, which puts buildx back on a plain Docker v2 manifest. Pulling was never affected — Docker handles OCI fine — so this only changes what the update check can read. This matters most on a release: users whose update status reads "not available" are never told a new version exists. Cancel superseded builds. #199 and #200 merged 13 seconds apart. Both started a build, and the older commit's run finished two seconds later, so it won the :dev tag and left it pointing at a commit missing the newer merge. A concurrency group keyed on the ref cancels the stale run so :dev always tracks the newest push. Release builds use their own ref and are unaffected. No change to which events publish or to the tags produced.
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
2 participants
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.
Why
The publish job currently gates on a push to
dev:There's no
devbranch in this repo, so that half never fires and a published release is the only thing that produces an image. Merges tomainrun the test job and stop there.The practical effect: every published tag currently points at the same build.
So there's nothing for a user to pull when a fix is merged, and no way to confirm a fix works before it goes into a release. This came up on #197, where the reporter asked how to test the merged fix and Unraid correctly showed no update available.
What this does
Adds
mainalongsidedevon the job condition and on the:devtag rule, so every merge publishes a rollingghcr.io/<owner>/plexcache-d:dev.Release behaviour is untouched. Semver tags and
:lateststay release-only, so a merge tomaincannot move the stable tag:main:devdev:dev(unchanged):latest(unchanged)v3.0Keeping the
devcondition means nothing breaks if you create that branch later and want to move the rolling channel onto it.Two lines, and reverting is just removing
mainfrom the two conditions.Testing
After merge, the merge commit itself is a push to
main, so the workflow should run and publish:dev. To confirm:testandbuild-and-push.docker pull ghcr.io/studionirin/plexcache-d:dev:devdigest differs from:latest, and that:lateststill resolves to the 3.2.0 build.If you'd rather the rolling channel live on an actual
devbranch instead, happy to redo it that way — this was the smaller change of the two.