Applications
An ArgoCD Application links a directory in your deploy repository to a Kubernetes namespace. This page covers how your applications are set up on Platon, who can do what with them, and how to manage them.
Your applications
Each environment of your project is one ArgoCD Application:
| Environment | Application | Namespace | Created by |
|---|---|---|---|
| production | <project>-prod | gl-proj-<id>-prod | a fixed Application |
| staging | <project>-staging | gl-proj-<id>-staging | a fixed Application (only if staging is enabled) |
| review | <project>-review-<branch-slug> | gl-proj-<id>-review-<branch-slug> | the ApplicationSet, one per branch |
<project> is the last part of your GitLab project's URL, in lowercase (for example hello-world), and <id> is the project ID. All of a project's applications belong to the ArgoCD project gl-proj-<id>.
To list only your applications in the UI, filter on the labels gitlab-project-name, gitlab-project-id or environment.
Application states
Every application in ArgoCD has two independent status indicators:
| Status | Values | Meaning |
|---|---|---|
| Sync status | Synced / OutOfSync | Whether the cluster matches what is in Git |
| Health status | Healthy / Progressing / Degraded / Missing | Whether the Kubernetes resources are running correctly |
An application can be Synced but Degraded (manifests applied but pods are crashing), or OutOfSync but Healthy (a new version is waiting to be synced).
Sync policies
| Review | Staging | Production | |
|---|---|---|---|
| Automatic sync | yes | no | no |
| Prune (delete resources removed from Git) | yes | on manual sync only | on manual sync only |
| Self-heal (revert manual changes in the cluster) | yes | no | no |
All applications use server-side apply.
Review environments: automatic sync
ArgoCD checks the deploy repository every 3 minutes and applies changes on its own. Resources you remove from manifests/ are deleted from the cluster, and changes made directly with kubectl are reverted to what is in Git.
Automatic sync can be turned off for a single review application, for example to debug something directly in the cluster.
Production and staging: manual sync
ArgoCD shows a new version as OutOfSync, but does not apply it until someone clicks Sync. This gives you explicit control over when production changes.
To deploy, open the application and click Sync → Synchronize. Tick Prune if you removed resources from your manifests and want them deleted.
Pre-sync hook
Every sync starts with a short pre-sync hook from Platon's argocd-hooks repository, which waits a few seconds so the namespace is ready before your resources are applied. You will see it in the application's resource tree. It needs no action from you.
Permissions
Access to your applications follows your role in the GitLab group that owns the project:
| Action | Developer | Maintainer |
|---|---|---|
| View applications and logs | yes | yes |
| Sync review and staging | yes | yes |
| Sync production | no | yes |
| Run resource actions (e.g. restart a Deployment) | yes, except production | yes |
| Open a terminal in a pod (exec) | no | yes |
| Delete a Pod, Service, ConfigMap, PersistentVolumeClaim or NetworkPolicy | no | yes |
Rolling back
Through Git (recommended)
Since every deployment comes from a Git commit, the most reliable rollback is to revert in your source repository:
- Find the commit that introduced the problem with
git log. - Revert it:
git revert <commit-hash> - Push. The pipeline renders and commits the reverted manifests.
- For production and staging, click Sync in ArgoCD.
Through ArgoCD (production and staging)
For a quick rollback while you prepare a fix, use ArgoCD's history:
- Open the application and click History and Rollback.
- Pick an earlier deployment and click Rollback.
A rollback in ArgoCD does not change Git. The application stays OutOfSync, and the next sync deploys the latest version again. Revert in Git as well.
ArgoCD does not allow rollback while automatic sync is on, so for review environments, revert in Git or push a fix.
Removing an environment
Review environments are removed when:
- you run the manual
stop-reviewjob in the branch's pipeline (or click Stop on the environment in GitLab under Operate → Environments), - the branch is deleted, or
- 14 days have passed since the last deployment.
Stopping removes the environment's directory from the deploy repository, and ArgoCD then deletes the application, its resources and the namespace.
Production and staging have no stop job. To remove one, disable it in your .gitlab-ci.yml (with-production: false or with-staging: false).
Don't delete applications in the ArgoCD UI: you don't have permission, and the ApplicationSet would recreate review applications anyway.
Using the ArgoCD CLI
The argocd CLI lets you manage applications from your terminal without opening the UI. Applications are referred to as <project-name>/<app-name> or simply <app-name>.
Install
# macOS
brew install argocd
# Linux
curl -sSL -o /usr/local/bin/argocd \
https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-amd64
chmod +x /usr/local/bin/argocd
Log in
argocd login argocd.argocd-test.sandbox.platon.sikt.no --sso --grpc-web #TODO: Replace with prod url
The --sso flag opens a browser window for Feide authentication. Your session token is stored locally and reused for subsequent commands.
List your applications
argocd app list -l gitlab-project-name=<project>
Inspect an application
argocd app get <project>-prod
This shows sync status, health status, the target Git revision, and a summary of all managed resources.
Sync
argocd app sync <project>-prod
To also delete resources that were removed from Git:
argocd app sync <project>-prod --prune
Wait for an application to become healthy
argocd app wait <project>-prod --health --timeout 120
Roll back
argocd app history <project>-prod
argocd app rollback <project>-prod <history-id>