Example project showcasing how power users can leverage the Replicated CLI Tools to manage kots YAMLs using a git repository.
This repo is a GitHub Template Repository. You can create a private copy by using the "Use this Template" link in the repo:
You should use the template to create a new private repo in your org, for example mycompany/kots-app or mycompany/replicated-starter-kots.
Once you've created a repository from the template, you'll want to git clone your new repo and cd into it locally.
You'll need to set up two environment variables to interact with vendor.replicated.com:
export REPLICATED_APP=...
export REPLICATED_API_TOKEN=...
REPLICATED_APP should be set to the app slug from the Settings page:
Next, create an API token from the Teams and Tokens page:
Ensure the token has "Write" access or you'll be unable create new releases. Once you have the values, set them in your environment.
export REPLICATED_APP=...
export REPLICATED_API_TOKEN=...
You can ensure this is working with
make list-releases
Once you've made changes to replicated.yaml, you can push a new release to a channel with
make release
By default the Unstable channel will be used. You can override this with channel:
make release channel=Beta
This repo contains a GitHub Actions workflow for ci at ./.github/workflows/main.yml. You'll need to configure secrets for REPLICATED_APP and REPLICATED_API_TOKEN. On every push this will:
- Ensure a channel exists for the branch that was pushed to
- Create a release based on the contents of
There is a file kurl-installer.yaml that can be used to manage kurl.sh installer versions for an embedded Kubernetes cluster. This isn't released by default in the GitHub action, but it can be released, either locally or in CI, by running the following.
make release-kurl-installer
There is also a Makefile.advanced with a powerful workflow for tagging and releasing new versions.
MIT