Previewing Config Changes

In addition to previewing code changes through container images built from work-in-progress pull requests or branches, you can use workspaces to preview changes to application configuration such as flags and environment variables. These configuration changes can be previewed in their own workspace or alongside code changes.

Workspaces support two kinds of configuration changes, which can be mixed and matched.

Ephemeral Config Changes

Ephemeral changes are managed through the Signadot Dashboard. They are typically used to alter configuration in ways that only make sense temporarily in the context of testing.

For example, you might set a flag or environment variable that tells the workspace's version of your service to talk to a special test database you've populated with a schema change you're proposing. Setting this as an ephemeral override in the web console allows you to avoid touching raw Kubernetes manifests, and ensures that you can't accidentally include the temporary change in your final commit to source control.

Kubernetes Manifest Changes

If you store Kubernetes manifests like Deployment specs in a git repository, either alongside your code or separately, you can preview changes to those manifests by editing them in a pull request or branch. Just like with code changes in a PR or branch, this lets you exercise the new value in an end-to-end environment before merging.

Repository Setup

To determine how to apply manifest changes to a workspace, the Signadot operator running in your Kubernetes cluster needs to be able to clone the relevant git repository and analyze its contents. This setup procedure should be performed once for each repository that contains manifests you'd like to preview.

Configure signadot.yaml

Each repository can optionally contain a signadot.yaml file at its root to tell Signadot how to interpret the repository's contents. To analyze manifest changes in a repository, this file must exist and have a manifests section defined. See the Repository Configuration reference page for a description of the options.

Create a deploy key

To get secure access to your repository, which is assumed to be private, the Signadot operator needs to be given an SSH private key whose corresponding public key has been granted read access. Note that both this SSH key and the contents of your repository are only stored and used in your own Kubernetes cluster, since the Signadot operator performs analysis locally by running Jobs as needed.

First, generate a new SSH public/private key pair. Note that GitHub only allows each key to be linked to one repository, so you'll need to generate a separate SSH key for each repository.

mkdir -p deploy-keys
ssh-keygen -t ed25519 -C signadot -f deploy-keys/{org}_{repo} -P ''

Replace the file name {org}_{repo} with your actual GitHub user or org name and repository name, separated by an underscore. For example, if your repository URL is github.com/foo/bar then use the filename deploy-keys/foo_bar. This will generate both a private key file (with no extension) and a public key file (with a .pub extension). Add the contents of the public key file ({org}_{repo}.pub) as a deploy key in your repository settings.

Finally, create or update a Secret named deploy-keys in the signadot-operator namespace to give the operator access to the private keys.

kubectl -n signadot-operator create secret generic deploy-keys \
  --dry-run=client --from-file=deploy-keys/ -o yaml \
  | kubectl -n signadot-operator apply -f -

Activate Kubernetes manifest previews for the repository

Once you've completed the above setup steps for a repository, use the Signadot Dashboard to enable git-based features on it.

Note that once you do this, Workspaces will expect to find a valid signadot.yaml file in each branch of that repository, so some branches may need to be rebased or have the main branch merged into them if you added the signadot.yaml file recently.


Did this page help you?