Approving Changes

Every change to your managed data plane, whether Tetrate's automation proposed it or you did, arrives as a pull request in your GitOps repository and waits there. You release it by commenting /approve on it. The seeded automation reads that comment, checks the request, and merges it. This page covers the commands, the three checks they drive, and what makes an approval expire.

Commands

Leave any of these as a comment on the pull request. The command has to be the first word of the comment, and an explanation can follow it on the same line, so /hold change freeze until Monday works.

Comment	What it does
/approve	Releases the change. Merges it when every check is green.
/unapprove	Withdraws that approval.
/hold	Pins the request shut, even once approved.
/unhold	Lifts the hold.
/merge	Merges now, if every check is green.
/close	Closes the request. A later scheduled run opens it again if the upgrade is still pending.
/help	Posts this list on the request itself.

Anyone with access to the repository can use them, which on the managed data plane is everyone Tetrate has assigned to your customer. Anything that is not one of these commands is ignored without a reply, so you can discuss a change in the comments without the automation answering.

Approving a request that is not ready to merge is harmless: /approve records your approval and replies with whatever is still blocking. Lifting a hold with /unhold then merges the request on the spot. A request waiting on Tetrate merges once the review lands and someone comments /merge, because a Tetrate review sets the check without deciding that the moment is right for your cluster.

The Three Checks

Every pull request carries three checks that say exactly where it stands:

Check	What it means	What turns it green
customer-approval	Yours: whether your organization has released this change.	Someone comments /approve.
customer-hold	The pin: whether someone has asked for this to wait.	Nobody has commented /hold, or someone has since commented /unhold.
tetrate-approval	Whether Tetrate has to look at the change.	The request touches only files you own, or someone at Tetrate approves it.

The files you own for this purpose are values-versions.yaml, values-customer.yaml, and .github/upgrades.yaml, at any level of the repository. A request confined to those needs nothing but your approval, which is why an automated upgrade merges the moment you release it. A request touching anything else, a chart, a template, or the automation itself, waits for a Tetrate review as well, and that includes requests Tetrate opened.

A hold leaves customer-hold pending rather than failing it. Holding is a decision to wait, not something that went wrong, and a red cross on a pending upgrade reads as breakage. Two labels mirror the state so you can scan a list of requests without opening them: approved and on-hold.

Approval Binds to the Commit

An approval applies to the exact commit it was given on, so pushing a new commit clears it and what you approved is always what merges. Two ordinary events count as new commits:

• A newer release landing on an open upgrade pull request. The automation updates the request in place rather than opening a second one, and the update asks for your approval again.
• The Update branch button, which brings a request that has fallen behind main up to date by adding a commit to it.

In both cases the request goes back to waiting for /approve, and re-running the checks never silently revokes an approval that still stands on the current commit.

Choosing How Approval Merges

.github/upgrades.yaml decides what /approve does:

merge-on-approval: true   # merge as soon as every check is green
merge-method: squash      # merge, squash or rebase

With merge-on-approval set to false, /approve only marks the request and says so, and /merge lands it. Split them when the decision to release and the moment of the rollout belong to different people or different hours.

The settings file is one of the files you own, so change it the way you change any other: open a pull request, and approve it yourself.

Next Steps

• Receive managed upgrades for what Tetrate's automated requests contain and how to stage them across environments.
• Work with your repository when the change you want to release is your own customization.
• Read Managed Data Plane for why Git is the only channel between Tetrate and your clusters.