theia: record studio-web/theia as the IDE image source, repoint the default - #8
theia: record studio-web/theia as the IDE image source, repoint the default#8NRGGIT wants to merge 1 commit into
Conversation
… default The session image moved out of fabric-poc into theia/ in b51b18d, and the configs were repointed with it — but the code default and the prose were not. This finishes that move. studio_session's default_image() still returned ghcr.io/constructorfabric/fabric-poc/cf-studio-theia:edge. Every shipped config/*.yaml overrides it, so it only surfaces when studio_session.image is unset — and then the gear reaches for a private package in a repo that no longer builds it. It now returns the studio-web image, which is what release.yml's images job actually publishes ($IMAGE_PREFIX resolves to ghcr.io/constructorfabric/studio-web) and what all five configs already name. ADR-0003 gets an amendment rather than a rewrite: the Context and Decision stay as written on 2026-07-30, and the new section records the source ref the prototype came from (fabric-poc@main:poc/theia, last commit 7fbf5fc3), how it arrived (b51b18d, verbatim git archive, 325 files, CRLF->LF), the two follow-ups that put theia/ ahead of poc/theia, why it lives here, and that the session contract — per-workspace container, loopback bind, credentials from the environment — is untouched. README and backend-handover said the image is built in fabric-poc by theia-image.yml. They now name release.yml's images job and the local build command that works from this tree. Signed-off-by: Roman Novikov <roman.novikov@constructor.tech>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughThe documentation records Theia as a local image source under ChangesTheia image alignment
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This PR repoints the fallback IDE image to the studio-web image and updates the related documentation; no actionable merge-blocking risk remains beyond normal checks and review. Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Closing — not needed as a PR. The work stays on the |
Source-reference decision
The prototype is already here. The task this PR closes was to import
Andrej's Theia prototype into Studio Web and decide where it should live. That
import already happened — by Andrej, on main — and this PR records the decision
and finishes the parts the import left behind.
constructorfabric/fabric-poc@main, pathpoc/theia7fbf5fc3— "Bind the portal bridge so an embedded session can hear the portal", 2026-08-06 (the last commit to touchpoc/theia)b51b18d— "theia: bring the IDE session image into this repo, off fabric-poc", 2026-08-11 — verbatimgit archive, 325 files, CRLF→LF0824412,477b90c(2026-08-13) — codex agent in-session; addedtheia/docker/codex-studio.shstudio-web/theia— notfabric-poc/poc/theiaWhy
studio-web/theia. One product was shipping from two repositories ontwo version schemes: backend and frontend on
v*out of here, the IDE image ontheia-v*out of there, so no single tag described a working stack. Keeping theimage beside the gear that launches it also puts the ADR, the
studio-sessionconfig and the Dockerfile in one diff when the env contract changes.
theia/is ahead ofpoc/theia, not a copy of it — verified by file set,not by assumption:
Nothing under
poc/theiais missing here, so no source needed copying andthere is no ref to import from. Syncing the other direction would lose the two
follow-up fixes.
Changes
One real defect.
studio-backend/src/studio_session/config.rs:111—default_image()still returnedghcr.io/constructorfabric/fabric-poc/cf-studio-theia:edge. All fiveconfig/*.yamloverride it, so it only surfaces whenstudio_session.imageisunset — and then the gear reaches for a private package in a repo that no
longer builds it. It now returns the studio-web image.
ADR-0003 gets an amendment, not a rewrite. The Context and Decision stay as
written on 2026-07-30 — an ADR records a decision as taken. The new section
records the source ref, how the tree arrived, why it lives here, the
build/publish path, and that the session contract is untouched. A pointer under
Status:keeps a reader from trusting the stalefabric-poc/poc/theiain theoriginal prose.
Docs.
README.mdanddocs/backend-handover.mdsaid the image is built infabric-pocbytheia-image.yml. They now namerelease.yml'simagesjoband a local build command that works from this tree.
Session contract — unchanged
Nothing here touches
studio-session's behaviour; the only executable change isone default string. Per ADR-0003, still true after this PR:
subject_tenant_id().bind_host: "127.0.0.1", allocated from the configured range.STUDIO_REGISTRY_USER/STUDIO_REGISTRY_TOKENfrom the environment; the Docker API ignoresdocker login's client-side store, which is why they are explicit.always_pull: truerefreshes the mutableedgetag, falling back to the local copy when the pull fails.Verification
Cross-checked every image reference in the repo — the new default matches the
publish path and all five configs:
release.yml:29setsIMAGE_PREFIX = ghcr.io/${{ github.repository }}→ghcr.io/constructorfabric/studio-webrelease.yml:163-173builds-f theia/Dockerfileand pushes$IMAGE_PREFIX/cf-studio-theia:$tconfig/{dev,docker,oidc,postgres}.yaml→ghcr.io/constructorfabric/studio-web/cf-studio-theia:edgeconfig/k8s.yaml→ the same image through the Harbor GHCR proxyconfig.rsdefault → now identical to the fourNo secrets. The diff adds no credential-shaped string. I also scanned the
imported
theia/127.0.0.1.har(42 MB, came in withb51b18d) for auth headers,cookies and token patterns — clean; the
eyJ…hits are base64 page bodies, notJWTs. It is covered by
*.harintheia/.dockerignore, so it never enters thebuild context. It is repo bloat, not a leak, and removing it is out of scope
here.
What I could not run locally, and why
Stated plainly rather than implied — CI is the verification for this PR:
cargo fmt/clippy/test— not run. This machine has no Rusttoolchain (
rustcandrustupabsent), and the backend's path dependenciesneed a
gears-rustsibling checkout that is not present.ci.ymlchecks outgears-rustand runs fmt, clippy-D warnings, build, test and the--list-gearssmoke on this PR. The change is a string literal in an existingfn … -> String, so it cannot alter types or control flow.docker build -f theia/Dockerfile theia— not run. The Docker daemon isnot running on this machine (
/Users/…/.docker/run/docker.sockabsent), so theDocker path was unavailable, not skipped. Note the build context has not
changed since
b51b18d, whichrelease.ymlhas been building on every mainpush since.
POST /studio-session/v1/sessions→confirm loopback bind) — blocked by the same two, since it needs both the
backend binary and Docker.
Happy to run either locally on request — the Docker build takes ~10 min and
needs network for the Theia plugin downloads.
Summary by CodeRabbit
Documentation
Configuration
constructorfabric/studio-web.