Idea / not scheduled. The extension-side half of Chrison-Homelab/Homelab#409, which tracks standing a gallery up at all.
Why
The pipeline already has three channels — rolling preview, github-releases, and the two marketplaces behind approval gates. What none of the GitHub ones can give is automatic updates: VS Code only tracks versions for extensions it got from a gallery, so a .vsix downloaded from a release is a one-shot install forever.
A gallery at gallery.fallout.build would make the preview channel behave like a real extension feed — install once, updates thereafter — without needing a public marketplace presence for pre-release builds.
What it would need here
- A fourth publish target.
IPublishVsix already models registries as data (VsixPublishTarget + VsixRegistry) and the --publish-vsix-to selector already exists, so this is a new enum value plus a target entry, not a new pipeline.
- How publishing works depends on which gallery (see #409):
- Microsoft Private Marketplace — extensions are published by dropping
.vsix files into the container's storage (mounted volume or Azure Artifacts), not through a CLI. That's a copy/upload step, so it likely wants its own small tool wrapper or task rather than reusing VsceTasks/OvsxTasks.
- Open VSX —
OvsxTasks covers it today via SetRegistryUrl. Zero new tooling.
- coder/code-marketplace — has its own CLI for adding extensions.
- A
gallery environment in the repo, matching the existing per-channel environment pattern. Ungated seems right for an in-house preview feed.
- HTTPS on
gallery.fallout.build — VS Code refuses a plaintext gallery, so this needs a real certificate.
Decision to make deliberately
A gallery on the project's own domain implies public-read, which makes it a genuine third distribution channel rather than a homelab convenience. That's a different security posture from "my network", and it matters because no gallery option supports authentication with VS Code — access control can only come from the network layer. Publishing Fallout extensions to a public gallery.fallout.build means anyone who knows the URL can consume them.
If the Microsoft option is chosen, there's a second constraint: consumers need a GitHub Copilot Enterprise/Business or GitHub Enterprise seat to connect at all, which makes it unsuitable as a public channel and fine as an internal one.
Note on the version scheme
No version-scheme change needed. The patch component is a Nerdbank.GitVersioning git height, so every build already carries a unique number and a gallery can hold the whole sequence without collisions. This is also why publishing previews as pre-release never consumes a number a stable release wants.
Blocked on
Chrison-Homelab/Homelab#409 — the gallery has to exist first. Options and trade-offs live there rather than duplicated here.
Idea / not scheduled. The extension-side half of Chrison-Homelab/Homelab#409, which tracks standing a gallery up at all.
Why
The pipeline already has three channels — rolling
preview,github-releases, and the two marketplaces behind approval gates. What none of the GitHub ones can give is automatic updates: VS Code only tracks versions for extensions it got from a gallery, so a.vsixdownloaded from a release is a one-shot install forever.A gallery at
gallery.fallout.buildwould make the preview channel behave like a real extension feed — install once, updates thereafter — without needing a public marketplace presence for pre-release builds.What it would need here
IPublishVsixalready models registries as data (VsixPublishTarget+VsixRegistry) and the--publish-vsix-toselector already exists, so this is a new enum value plus a target entry, not a new pipeline..vsixfiles into the container's storage (mounted volume or Azure Artifacts), not through a CLI. That's a copy/upload step, so it likely wants its own small tool wrapper or task rather than reusingVsceTasks/OvsxTasks.OvsxTaskscovers it today viaSetRegistryUrl. Zero new tooling.galleryenvironment in the repo, matching the existing per-channel environment pattern. Ungated seems right for an in-house preview feed.gallery.fallout.build— VS Code refuses a plaintext gallery, so this needs a real certificate.Decision to make deliberately
A gallery on the project's own domain implies public-read, which makes it a genuine third distribution channel rather than a homelab convenience. That's a different security posture from "my network", and it matters because no gallery option supports authentication with VS Code — access control can only come from the network layer. Publishing Fallout extensions to a public
gallery.fallout.buildmeans anyone who knows the URL can consume them.If the Microsoft option is chosen, there's a second constraint: consumers need a GitHub Copilot Enterprise/Business or GitHub Enterprise seat to connect at all, which makes it unsuitable as a public channel and fine as an internal one.
Note on the version scheme
No version-scheme change needed. The patch component is a Nerdbank.GitVersioning git height, so every build already carries a unique number and a gallery can hold the whole sequence without collisions. This is also why publishing previews as pre-release never consumes a number a stable release wants.
Blocked on
Chrison-Homelab/Homelab#409 — the gallery has to exist first. Options and trade-offs live there rather than duplicated here.