unkin/jellyfin-ha
4
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

build: container build from the unkin jellyfin-ha-src fork #3

Merged
benvin merged 4 commits from benvin/jellyfin-ha-build into main 2026-08-11 21:13:47 +10:00
Conversation 0 Commits 4 Files Changed 8
+237 -2
unkinben commented 2026-08-11 07:25:17 +10:00
Owner
Copy Link
Copy Source

Why

Stand up the jellyfin-ha container build end to end in a single mergeable change: build scaffolding, push images to the artifactapi registry, and source from our own fork so local HA patches can be carried and pinned. Merging this one PR lands all commits.

How

  • Add jellyfin-ha container build — Makefile + .woodpecker/build.yaml (PR validation: dotnet publish the pinned source, dry-run the runtime image) and .woodpecker/docker.yaml (build + push on v* tags), pinning the source via UPSTREAM_REF.
  • Push images to artifactapi — the release pipeline pushes the runtime image to the artifactapi local docker registry (artifactapi.k8s.syd1.au.unkin.net/docker-internal/jellyfin-ha) rather than Gitea. The push is unauthenticated in-cluster on serviceAccountName: default, mirroring the established estate convention (pdbmux/encapi/cephrgw-operator .woodpecker/docker.yaml) — no registry credentials or dedicated ServiceAccount are required for docker-internal.
  • Source from the fork — the clone URL in the Makefile and both pipelines points at https://git.unkin.net/unkin/jellyfin-ha-src.git. UPSTREAM_REF stays at d4f9c12c22d3a640f3b0a3622b23b8cd01d044ad (== seeded fork main), so the produced image is byte-identical for now; the feature bump is a later change.
  • Pin the .NET SDK to 9.0 — the pinned fork's global.json requests sdk 9.0.0 (rollForward latestMinor); the publish steps in build.yaml and docker.yaml referenced sdk:10.0, which fails the pinned build. Both now use mcr.microsoft.com/dotnet/sdk:9.0.

Supersedes #1 and #2, which are combined here so a single merge carries all commits. Source now comes from the fork instead of the upstream GitHub tree.

Follow-up (non-blocking): mcr.microsoft.com is not currently fronted by an artifactapi remote; per the images policy the SDK image could later be proxied, but no mcr remote exists yet.

## Why Stand up the jellyfin-ha container build end to end in a single mergeable change: build scaffolding, push images to the artifactapi registry, and source from our own fork so local HA patches can be carried and pinned. Merging this one PR lands all commits. ## How - **Add jellyfin-ha container build** — Makefile + .woodpecker/build.yaml (PR validation: dotnet publish the pinned source, dry-run the runtime image) and .woodpecker/docker.yaml (build + push on v* tags), pinning the source via UPSTREAM_REF. - **Push images to artifactapi** — the release pipeline pushes the runtime image to the artifactapi local docker registry (artifactapi.k8s.syd1.au.unkin.net/docker-internal/jellyfin-ha) rather than Gitea. The push is unauthenticated in-cluster on `serviceAccountName: default`, mirroring the established estate convention (pdbmux/encapi/cephrgw-operator .woodpecker/docker.yaml) — no registry credentials or dedicated ServiceAccount are required for docker-internal. - **Source from the fork** — the clone URL in the Makefile and both pipelines points at https://git.unkin.net/unkin/jellyfin-ha-src.git. UPSTREAM_REF stays at d4f9c12c22d3a640f3b0a3622b23b8cd01d044ad (== seeded fork main), so the produced image is byte-identical for now; the feature bump is a later change. - **Pin the .NET SDK to 9.0** — the pinned fork's global.json requests sdk 9.0.0 (rollForward latestMinor); the publish steps in build.yaml and docker.yaml referenced sdk:10.0, which fails the pinned build. Both now use mcr.microsoft.com/dotnet/sdk:9.0. Supersedes #1 and #2, which are combined here so a single merge carries all commits. Source now comes from the fork instead of the upstream GitHub tree. Follow-up (non-blocking): mcr.microsoft.com is not currently fronted by an artifactapi remote; per the images policy the SDK image could later be proxied, but no `mcr` remote exists yet.
unkinben added 3 commits 2026-08-11 07:25:18 +10:00
Add jellyfin-ha container build a0983157a0 
Build-orchestration for the jellyfin-ha Jellyfin fork: pins an upstream
commit (UPSTREAM_REF), publishes the .NET 10 server, and builds/pushes the
runtime image to git.unkin.net/unkin/jellyfin-ha on v* tags.

- UPSTREAM_REF pinned to d4f9c12
- Dockerfile.runtime (vendored runtime-only image + jellyfin-web 10.11.6)
- .woodpecker/{build,docker}.yaml (publish + docker-buildx, k8s resources)
- Makefile (publish/build + patch/minor/major release tagging)
ci: push images to artifactapi registry instead of gitea 84f9158e9b 
Hard switch of the docker push target from the Gitea registry to the
artifactapi local docker registry (docker-internal); the Gitea VM and its
registry are being retired. Drops the droneci/DRONECI_PASSWORD creds since
artifactapi accepts unauthenticated in-cluster pushes. Also repoints the Makefile IMAGE and README image paths.

Claude-Session: https://claude.ai/code/session_015ur3i7D2azsMAWTSVABApv
build: source from the unkin jellyfin-ha-src fork 9f8d9014d3 
Why:
- The build should pull from our own source fork so local HA patches can be
  carried and pinned, rather than cloning the upstream GitHub tree directly.

How:
- Point the clone URL in the Makefile and both Woodpecker pipelines at
  https://git.unkin.net/unkin/jellyfin-ha-src.git.
- Keep UPSTREAM_REF at d4f9c12c22d3a640f3b0a3622b23b8cd01d044ad, which is the
  seeded fork main, so the produced image is byte-identical for now; the
  feature bump is a later change.
unkinben added 1 commit 2026-08-11 20:41:59 +10:00
ci: pin .NET SDK image to 9.0 to match global.json
ci/woodpecker/pr/build Pipeline was successful
Details
26e57c8655 
The pinned jellyfin-ha-src fork sets global.json sdk 9.0.0 (rollForward
latestMinor), so the publish steps in build.yaml and docker.yaml must run
on the .NET 9 SDK. They referenced sdk:10.0, which fails the pinned build.
Repoint both publish steps to mcr.microsoft.com/dotnet/sdk:9.0.
unkinben force-pushed benvin/jellyfin-ha-build from f99714f184 to 26e57c8655 2026-08-11 20:41:59 +10:00 Compare
benvin merged commit ac507021f3 into main 2026-08-11 21:13:47 +10:00
benvin deleted branch benvin/jellyfin-ha-build 2026-08-11 21:13:47 +10:00
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
bug
Something is not working
 duplicate
This issue or pull request already exists
 enhancement
New feature
 help wanted
Need some help
 invalid
Something is wrong
 question
More information is needed
 wontfix
This won't be fixed
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
benvin (BenVincent) unkin-agent (Unkin Agent) unkinben (Ben Vincent)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: unkin/jellyfin-ha#3
Delete Branch "benvin/jellyfin-ha-build"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?