Requesting a deploy

What happens when you press Deploy

The click is intercepted before Bubble's own handler runs, so nothing has been deployed and nothing has been changed. What you get instead is a form, and what comes out of it is a deploy request.

1. Sign in with Google.

   The same account you use in the console. Once per session, not once per deploy.

2. Name the Linear issue.

   What this deploy is for. The request is commented back onto that issue, so the ticket and the deploy point at each other without anybody maintaining the link.

3. Describe the change, and the rollback plan.

   Both are read by the person deciding, and both end up in the evidence. "Revert to the previous version" is a legitimate rollback plan; leaving somebody to guess at 2am is not.

4. Pick an approver.

   This is routing, not permission — see who can actually decide. It chooses whose notifications go out, and you can hand it to somebody else later without losing the request.

5. Wait for a decision, then deploy.

   Once somebody approves, the gate opens for a single use, for fifteen minutes, for that deploy of that app. Bubble's own deploy dialog appears with the description pre-filled with the request id — leave it there, it is how the deploy is matched back to the approval afterwards.

While your request is waiting

The branch you raised it from is held. Everyone who opens that branch in the Bubble editor sees a panel listing what is pending on it: the issue, the change, the rollback plan, who raised it and when the window closes. Whoever is looking at it can approve or reject it right there.

You will see the same list, with the reason you cannot decide your own request and a link to hand to somebody who can.

This exists because the gate stops an unapproved deploy at the moment somebody presses Deploy, which leaves a gap: between a request being raised and decided, the branch it came from is still editable. Without the panel, what ships need not be what was reviewed — and the record would say it was.

When the gate will not open

Read what it says, because the four cases need different things from you:

• The app has not been added. An administrator adds it in the console. Until then BuildGate does not know whose app it is, and guessing would be worse than refusing.
• Your request is still pending. Nobody has decided it yet. The panel on the branch names who it is routed to; any approver can decide it, so if that person is unavailable, ask another.
• It was rejected. The note from whoever rejected it says why. Rejections cannot be undone, so fix the thing and raise a new request.
• It expired. Approval opens the gate for fifteen minutes and a single deploy. Raise it again — this is a short window on purpose, so an approval cannot be banked and spent on a later change.

When BuildGate itself is down

The gate fails closed. If the extension cannot reach the service, the Deploy button stays shut rather than falling open — a control that stops controlling during an outage is not a control.

For the deploy that genuinely cannot wait there is break-glass: a code your organization holds, plus a written reason. The extension does not ask permission — it cannot, because the service is the thing that is unreachable. It takes the code and the reason, lets the deploy proceed, and queues the report until the service comes back.

What that means in practice:

• Every break-glass deploy becomes an open exception. A correct code and a wrong one both do; the difference is that the record says which. A wrong code does not undo a deploy that already happened, it just makes the finding say so.
• The reason you type is the evidence. It is read later by whoever closes the finding, and it is in the export. Write the sentence you would want to be reading.
• Owners and admins are told as it happens, on whichever channels are configured, and again in the daily digest until somebody closes it.