Let a build be deleted from the build area - #3425
Closed
dakshina99 wants to merge 10 commits into
Closed
Conversation
A default gateway is settled on the gateway now, so the pipeline builder drops its gateway step: the picker is a single-step environment list, the stage cards show only the environment, and the pipelines feature no longer reads /managed-gateways at all. The gateways feature gains the other half: a default switch on the create form, a Default badge in the list, and a mark-as-default action that hands the default over (never clears it, so an environment keeps one). The list is now filtered to the host's own gateway types, so the AI workspace shows AI gateways with the AI default while the publisher shows regular and event ones with theirs — until now each host listed every gateway regardless of type. Marking a default resends the gateway's current name and description because the update endpoint replaces the mutable fields rather than patching them. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Drop the star action from the gateways list and the explanatory text under the form's switch. The switch is the only way to mark a default now, which is enough on its own, so the list's row actions go back to edit, configure and delete — the Default badge still shows which gateway holds it. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The switch now sits after the environment picker, because what it should say depends on which environment is chosen, and it ticks itself when the gateway would be the first of its type there — which is when the backend makes it the default whether or not it was asked to. Otherwise it stays off. It is disabled until an environment is selected, since before that there is nothing for the gateway to be the first of. A manual toggle afterwards sticks, and is only re-derived when the environment or type changes. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
An environment runs a single build of an API at a time, so the deploy dialog now selects gateways rather than one gateway, and sends them in a single call that puts the same build on all of them. Each selected gateway gets its own endpoint field, because two gateways of one environment can serve different backends and a deployment owns its parameters. Gateways the API is already deployed on are ticked and locked with the reason given: the backend refuses a deploy that drops one, so offering to untick it would only produce an error — undeploying is how you stop deploying to a gateway. Retrying a single failed gateway still sends only that gateway, since it ships the build its peers already run and so leaves the environment on one build. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The deploy dialog decided a gateway was already deployed by testing for a deployment id. A stopped gateway keeps that id — it is how the deployment is identified — so undeploying a gateway left it ticked and locked, and there was no way to deploy or promote without it. Dropping it from the set is the whole point of stopping it. Locking now keys on the live status instead. Putting a stopped gateway back is also a deploy now rather than a revival of what it used to run: reviving its old deployment would put that build back while the rest of the environment had moved on. It deploys the build the environment is running, and says so when there is none to join. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…witch The build is a property of the environment now — every gateway in it runs the same one — so the environment card states it once instead of leaving it to be read off the gateway rows and compared. More than one build showing means the environment is split, which the deploy rules exist to prevent, so that is called out rather than quietly listed. Removes the per-gateway Redeploy button: putting a stopped gateway back is a deploy, and it goes through the dialog so it joins the build the environment is on. Stop is the only action on a serving gateway, and a stopped one offers none. Promoting no longer shows a build dropdown. The source environment runs one build and promotion carries that one forward, so the dropdown implied a choice the pipeline does not offer; the build is stated instead. The first gateway of a type in an environment also can no longer be unmarked as that environment's default: it becomes the default whatever the switch says, so offering to untick it was a lie. The Default badge is smaller, matching the sizing the pipeline cards already use. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Redeploy is no longer an operation, so a retry reporting "Redeploying" named something that does not exist any more. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The build sits on the right of the card header now, using the space the header was leaving empty, rather than on a row of its own below the name. Promotion is also gated on the environment having a build to carry forward. Once every gateway here is stopped the environment runs nothing, and the backend already refuses the promotion for that reason — the button was still offering it, so it offered an action that could only fail. The tooltip now says which of the two reasons applies: nothing deployed here, or no active gateway there. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
dakshina99
requested review from
AnuGayan,
Arshardh,
CrowleyRajapakse,
HeshanSudarshana,
HiranyaKavishani,
Krishanx92,
PasanT9,
RakhithaRR,
Tharsanan1,
ashera96,
chamilaadhi,
dushaniw,
hisanhunais,
malinthaprasan,
pubudu538,
renuka-fernando,
senthuran16,
tgtshanika,
tharikaGitHub and
tharindu1st
as code owners
September 11, 2026 07:44
dakshina99
requested review from
Induwara04,
Piumal1999,
Thushani-Jayasekera,
lasanthaS and
thivindu
as code owners
September 11, 2026 07:44
Contributor
|
Warning Review limit reachedNext included review available in 50 minutes. View limit detailsLimit details: You’ve used the included review currently available. This review ran on the open-source allowance, not this organization's plan, because the pull request author doesn't have an assigned seat. Waiting won't change this — ask an organization admin to assign them a seat, or add seats in Billing if every seat is already assigned, then retry. Review configuration: ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (24)
Comment |
Contributor
Author
|
Folded into #3421 — both commits are now on |
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
1 participant
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.
Purpose
An API keeps a limited number of builds. When automatic cleanup cannot reclaim one
— every stored build is held by a deployment on a gateway somewhere — deploying is
refused, and the deploy page offered no way out of it.
Approach
Delete lives in the Build Area, whose
renderBuildsis shared by the inlinelist and the All Builds drawer, so both get it from one change.
would otherwise have to stack one inside).
holding the build —
DEPLOYED,DEPLOYINGorUNDEPLOYING. Suspended andfailed deployments are deliberately not in that set: their builds are exactly the
ones automatic cleanup will not reclaim, so they are what this is for.
the page loaded, so the platform's refusal is what decides, and it surfaces
through the existing action toast.
descriptionnow shows under its id, which is what makes a list ofbuilds something you can choose from.
deleteBuildcallsDELETE /rest-apis/{apiId}/builds/{buildId}on the API's ownresource rather than through the project path — a build belongs to the API, not to
a pipeline — following the
GET /rest-apis/{apiId}call already in this client.The second commit drops the build-id card from the gateway card in favour of a
plain "Deployed " line. The build a gateway runs is already shown once on the
environment, so repeating it per gateway only contributed an
IDlabel withnothing beside it once the build had been reclaimed.
Also removed two comments left behind when the per-gateway redeploy was dropped: an
orphaned block documenting the removed
redeploymethod, and a "Deploys to onegateway" block sitting above the bulk-deploy function.
Automation tests
tsc --noEmitpasses. Verified on a local cluster against an API sitting at thelimit with five builds: the three held only by superseded deployments offer delete,
and the two a gateway is serving are disabled with the reason.
Related PRs
Stacked on #3421 — its commits appear in this diff until it merges; only
Let a build be deleted from the build areaandShow when a gateway was deployed instead of a build id cardbelong to this PR. Needs the build delete endpoint andthe build
descriptionfrom #3364.