fix: supply IDP login media assets for no-npm (rolling) builds

[DeepDiver1975]

Problem

The IDP login UI on owncloud/ocis-rolling:latest renders without its favicon, background image, and Inter font.

I pulled the latest rolling image, ran it (ocis init + ocis server), and checked the login page (/signin/v1/identifier/) by asserting every referenced asset resolves:

Asset	Status
theme.css, logo.svg	✅ 200
favicon.ico	❌ 404
media/background.7296b9ab..jpg	❌ 404
media/inter.d5c51099..woff2 (font)	❌ 404
media/inter.aadb65ac..ttf (font)	❌ 404

Root cause

Upstream oCIS commit da7ef6050 ("service/idp no-npm", OCISDEV-696, #12086) replaced the IDP React SPA with a server-rendered login page and a static theme.css. That theme.css references a favicon plus media assets (background + Inter web fonts, with mangled double-dot webpack hashes) that the commit never committed and provides no build step to generate. The IDP assets are embedded via //go:embed assets/* (services/idp/idp.go), so on master/rolling builds these files are simply missing → 404.

Our Dockerfile's no-npm else branch correctly skips pnpm build, but as a side effect also skipped the favicon fetch, and there was never anything supplying the media.

Release tags (e.g. 8.0.5) are unaffected — they still build the React SPA via pnpm build and serve a complete asset set from /signin/v1/static/ (verified: all 200).

Fix

In the no-npm branch of the node-builder stage, fetch the missing files:

• favicon from owncloud/assets (matching the pnpm path)
• media (background.jpg, inter.woff2, inter.ttf) recovered from the pre-no-npm parent commit 0239585…, written to assets/identifier/static/media/ at the exact names theme.css references.

Verification

Built the node-builder target from this branch against current master and confirmed all four assets land at the expected embed paths with byte sizes matching the originals (favicon, bg 88069, woff2 21624, ttf 803384). The embed→serve path is already proven (the existing theme.css/logo.svg serve 200 from the same tree on the live rolling container), so files present at build time will serve 200.

Note

This is a workaround pinned to a historical upstream commit. It should be removed once upstream ships the media assets (worth filing against owncloud/ocis).

🤖 Generated with Claude Code

[DeepDiver1975]

🤖 Automated review by Claude Code review agent.

Verdict: approve. This correctly supplies the IDP login media assets that the no-npm upstream layout fails to ship, and I verified the mechanics end-to-end.

Correctness (verified):

• The three pinned media URLs all resolve and the byte sizes match the PR body exactly: background.jpg → 200/88069, inter.woff2 → 200/21624, inter.ttf → 200/803384 (@02395858…, commit confirmed present upstream).
• theme.css on current master references exactly media/background.7296b9ab..jpg, media/inter.d5c51099..woff2, media/inter.aadb65ac..ttf — so the (intentional double-dot, webpack-mangled) output names at Dockerfile.multiarch:36,38,40 match the referenced names precisely.
• No silent-failure risk: every fetch uses curl -fsSL (non-2xx → non-zero exit) chained with &&, so a missing asset aborts the RUN layer rather than baking a broken image (:30-40).
• The favicon fetch in the else branch (:32-33) mirrors the pnpm branch (:27-28) — same source, no duplication/conflict since the two branches are mutually exclusive ([ -f package.json ]).
• Embed→serve path is already proven by the live-200 theme.css/logo.svg from the same tree, so build-time presence is sufficient.

Reproducibility: the media is pinned to an immutable commit via ARG IDP_MEDIA_REF (:22,34) — good, non-latest. The favicon still tracks owncloud/assets@main (:32), but that mirrors the pre-existing pnpm-path convention (:27), so it's consistent rather than a regression introduced here.

Conventions: comment block (:13-21) clearly documents the workaround, its upstream cause (OCISDEV-696 / da7ef6050), and the removal condition — matches the existing in-file documentation style. Worth filing the upstream owncloud/ocis issue mentioned in the PR note so this workaround can be retired.

CHANGELOG: n/a — Dockerfile/build fix, following this repo's established convention (build fixes #16–#19 added no CHANGELOG.md entry). The diff does not touch CHANGELOG.md.

Checks: all build/lint checks green (amd64 + arm64 across both 8.0.5 and rolling matrices, lint, lint-editorconfig). mergeStateStatus=BLOCKED reflects the pending required review, not a failing check.

[DeepDiver1975]

Closing this in favour of the upstream fix owncloud/ocis#12462 ("fix: service idp assets").

On reassessment, the missing IDP login assets are a problem that belongs upstream, not in this Docker build. #12462 fixes the real root cause: the parent .gitignore was excluding services/idp/assets, so the no-npm rewrite (#12086 / da7ef6050) never actually committed the favicon and media/* files that theme.css references. #12462 commits those binaries directly and adds services/idp/.gitignore with !assets + !assets/** (asset byte sizes match what this PR fetched: favicon 15086, background 88069, woff2 21624, ttf 803384).

Because the IDP assets are embedded via //go:embed assets/*, once #12462 merges the files land in the clone automatically and the next nightly rolling build picks them up — no change is needed in this Docker repo. The workaround here (re-fetching assets from the pre-no-npm parent commit) would just be dead code, so closing it.

[mklos-kw]

owncloud/ocis#12462 was merged upstream