Fetch and render cluster sync badges on environment page

Release notes

Did you ever wondered about the status of your GitOps deployments? Until now, you likely used kubectl or another 3rd party tool to learn the status of your Flux deployments. From now on, you can use the GitLab environments UI to quickly check the status of your deployments.

The deployments rely on Flux Kustomization and HelmRelease resources to gather the status of the given environment and require a namespace to be configured on the environment. By default, the GitLab searched a Kustomization, followed by a HelmRelease with the name of the given project's slug. You can customize the name GitLab looks for in the environment's settings.

Summary

This issue is to implement cluster sync status badges on the Kubernetes overview of the Environments page.

The design issue: #375449 (closed) and Figma link.

Example situation

We want to show a status for

• RailsApp
• Sidekiq
• KAS

Proposal

1. Use the project slug as the expected name for the Flux resource. The Flux resource can be a Kustomization or a HelmRelease. Kustomization having a preference if both exist.
2. Provide an input field under the environment settings to customize the name of the resource.
3. Document with examples and links to the Flux docs how Flux can be set up to wait for dependant resources.

Alternatives considered

Alternatives: Environment slug

Use the environment slug as the expected name for the Flux resource. The Flux resource can be a Kustomization or a HelmRelease. Kustomization having a preference if both exist.

As a Flux HelmRelease waits for its managed resources to be ready, including Kustomizations and Kustomizations can be configured to wait (using health checks), we can pick a single Flux resource, and that resource can aggregate the status of its dependant resources.

Alternatives: Flux labels

Flux sets the labels

• Kustomize sets kustomize.toolkit.fluxcd.io/name
• HelmRelease sets helm.toolkit.fluxcd.io/name

on the resources managed by Flux.

This approach is likely more complicated for the user. This can be seen if we look at the KAS service. The label value is set to Apps there. Having a environment called apps that points to the namespace of KAS is likely not what the user wants.

Alternative 2: custom label

We could have a custom label, like app.gitlab.com/environment: <environment name>. While this is definitely a possibility, it requires extra work from the user to set up the integration.

Task

Fetch the info needed within the project -> environment -> lastDeployment GraphQl query to show the sync badges according to the design.