Skip to main content
logoTetrate Patch ServiceVersion: alpha

Working with a Provisioned Repository

Instead of connecting your own repository, you can have Tetrate provision one for your organization. Tetrate creates it on GitHub with your products already in it, and the cluster onboarding installs Argo CD to deploy from it. Upgrades then arrive exactly as in any other repository: see Managed Upgrades.

This page covers what a provisioned repository holds beyond the common files, and how you change it.

Finding Your Repository​

Click My Repo in the sidebar to open it on GitHub. Every user in your organization gets read access to it automatically. The Upgrades view also names it, with a Provisioned by Tetrate badge.

Read access is the whole grant: every change, Tetrate's upgrades included, arrives as a pull request, and you release it with a command. See Approving and Releasing Changes.

What Is in It​

Each product starts with one environment, default. Next to the common files, each product directory holds:

.tetrate/teg/
├── values-tetrate.yaml        Tetrate's settings for your account
├── values-customer.yaml       your settings, for every environment
└── envs/default/
    ├── application.yaml       the Argo CD Applications deploying it
    ├── values-customer.yaml   your settings, for this environment only
    └── values-versions.yaml   the versions, kept current by upgrades

application.yaml holds two Argo CD Applications that pull Tetrate's charts directly: one for the product and one for its CRDs. The CRD Application never prunes, so removing the product, or a release dropping a CRD, never deletes the resources of that kind in your cluster.

The chart reads the values files in this order, later ones winning: values-tetrate.yaml, your product-wide values-customer.yaml, your environment's values-customer.yaml, and the versions file last.

The repository also holds bootstrap/, which the cluster onboarding uses to install Argo CD, and the automation under .github/.

Customizing Your Products​

Your customization, such as resource requests, node affinities or gateway placement, goes in the values-customer.yaml files, written in the product chart's own values keys:

  1. Fork the repository. Your accounts have read access, so the fork holds your branch.
  2. Edit the customer file at the level you mean: the product's file to affect every environment, an environment's file to affect only that one.
  3. Open a pull request against main in your repository.
  4. Comment /approve once your review is done. A change confined to your own files merges on your approval alone.
  5. Argo CD applies the merge on its next sync.
Change Git, not the cluster

Argo CD reverts a change made directly in a cluster on its next sync. What is on main is what runs.

What You Can Change​

FilesWho changes them
values-customer.yaml, at any levelYou. Upgrades never touch them.
values-versions.yamlUpgrades. You can hold an image back.
.github/upgrades.yamlYou: it decides whether /approve also merges.
Everything else, including values-tetrate.yaml and application.yamlTetrate. You can still propose a change; it waits for a Tetrate review.

An upgrade also moves the chart version in application.yaml. That is the one change to a Tetrate file that needs only your approval.

When You Stop Using It​

If your organization stops using a provisioned repository, Tetrate archives it rather than deleting it: the history stays readable, and clusters already deploying from it keep running what they run. They no longer receive upgrades.

Next Steps​