Upgrade
Do not roll back or downgrade without consulting our support team first. Certain scenarios may necessitate restoring the database from a pre-upgrade backup due to the complexity of reversing some database migrations.
KOTS-based installation
Upgrading the GitGuardian application
Prior to upgrading, ensure you back up your PostgreSQL database. For detailed instructions, refer to the Backup page.
The GitGuardian application can be updated through the KOTS Admin Console in the "Version History" tab. First, you need to check for updates. This can be done manually or automatically. Then, you can deploy a newer version by clicking the "Deploy" button.
You can find more information on the KOTS documentation.
During upgrades, workers are stopped but new commits are still queued and will
be processed after the upgrade. Upgrades do not stop the dashboard, but they
introduce a temporary delay in message processing and alerting.
We advise running upgrades during a low-traffic period.
Upgrading the GitGuardian application in Airgap
To upgrade the KOTS admin interface, follow the installation instructions: install the latest version of the KOTS plugin of your machine, download the latest KOTS bundle and upload these images to your registry. Then, instead of running the installation command, you will need to upgrade the KOTS application running in the cluster:
kubectl kots admin-console upgrade --namespace <namespace>
If needed, specify the Kubernetes namespace with --namespace (default namespace is used if not specified).
To upgrade the GitGuardian application, first download the latest application bundle on the download portal. Then go to your KOTS Admin Console on the "Version History", and click on "Upload new version". Upload the bundle and deploy it.
Required versions
KOTS Admin Console will show some versions as "Required".
If you have several versions to upgrade, you'll have to upgrade to each required version between your current version and your target version.
After each deployment, you should wait for the application to be fully upgraded. To that extent, you can monitor pods' status and wait for all pods to be live and all jobs to be completed.
watch kubetcl get po -n <namespace>
The application is restarted when all pods are in the running status:
Upgrading KOTS
Before upgrading GitGuardian, you must upgrade to KOTS for optimal performance and compatibility.
Please remember that regular upgrades of KOTS are necessary. GitGuardian releases are thoroughly tested with the latest KOTS release. To ensure full functionality and compatibility, some features may not perform as expected on older versions of KOTS. We strongly recommend staying updated with the most recent releases.
To check the KOTS plugin version, run the following command:
kubectl kots version
If there is an update available, follow the instructions and run this command:
curl https://kots.io/install | bash
For existing cluster, you will need to upgrade the KOTS application running in the cluster:
kubectl kots admin-console upgrade -n <namespace>
For embedded cluster, simply re-run the same installation command as outlined in the installation guide.
For further instructions on upgrading KOTS, refer to the Replicated documentation.
In some cases, the preflight checks may not detect the KOTS admin version change correctly, leading to failures even when using the required minimum KOTS version. To address this issue, follow these steps:
- Navigate to the KOTS Admin Console.
- Go to Config > Advanced Options.
- Adjust the number of email worker replicas (for example, from 2 to 1).
- Deploy your configuration change.
- Click the Check for update link.
- Run the preflight checks again.
- Once the preflight checks are completed, revert the change by restoring the number of email worker replicas to its original value.
Upgrading Kubernetes on Embedded Cluster
To upgrade your Kubernetes version for the embedded cluster, follow these steps:
- Simply re-run the same installation command as outlined in the installation guide.
If you're uncertain whether you're using the new or legacy GitGuardian architecture, you can explore the New GitGuardian Architecture page. If you're using the legacy architecture, follow the instructions in this legacy installation guide instead.
- To verify the Kubernetes version, execute the following command:
kubectl version
Helm-based Installation
Prior to upgrading, ensure you back up your PostgreSQL database. For detailed instructions, refer to the Backup page.
Run preflight checks
The preflight checks will work only from GitGuardian version 2024.4.0.
We strongly advise you to run our preflight script to ensure your existing cluster meets Gitguardian's requirements.
Retrieve the script from our public repository here
Specify an existing Kubernetes namespace using the -n option. If not specified, the script will run in your default namespace.
./preflights.sh -n <namespace> oci://registry.replicated.com/gitguardian/gitguardian -f local-values.yaml
Upgrading version
Log in to the registry with the following command:
helm registry login registry.replicated.com --username your.name@yourcompany.com
Upgrade the GitGuardian application in the Kubernetes cluster and namespace where it's installed:
helm upgrade <release-name> -n <namespace> oci://registry.replicated.com/gitguardian/gitguardian
Replace <release-name> with the name used during the initial installation (use helm ls to find it).
If needed, specify the namespace with -n (default namespace is used if not specified).
This will upgrade your application to the latest version. To upgrade to a specific version, use the --version flag:
helm upgrade <release-name> -n <namespace> oci://registry.replicated.com/gitguardian/gitguardian --version 2024.4.0
Updating application configuration
Modify the application configuration with an updated values file using the helm upgrade command.
Stick to the same version using the --version flag:
helm upgrade <release-name> -n <namespace> oci://registry.replicated.com/gitguardian/gitguardian --reuse-values --version 2024.4.0 -f updated-local-values.yaml
Replace <release-name> with the name used during the initial installation (use helm ls to find it).
If needed, specify the Kubernetes namespace with -n (default namespace is used if not specified).
Was this page helpful?
