lens-gitlab 0.1.0 → 0.2.0

package/CHANGELOG.md

@@ -2,6 +2,15 @@
 
 What changed in each version of this extension, newest first.
 
+## 0.2.0
+
+- A service deployed by image digest, or tagged `latest`, is matched to its commit when the workload carries `org.opencontainers.image.revision`.
+- A GitLab answer of 304, meaning nothing changed, no longer counts as the GitLab CLI failing. The last reading stays. An error status GitLab returns is reported as that error.
+- **Environments**: one project across the clusters that watch it, in columns ordered dev, then stage, then prod, with the commit or release each one runs.
+- GitLab's last successful deployment of an environment, beside the cluster of the same name. **production** also matches a cluster that follows `main`, `master` or `prod`. **Drift** opens the commits and merge requests between the two.
+- **Play** on a manual job, after confirming, which starts that job on GitLab.
+- **DORA** for a watched project, chosen from the menu: median lead time from commit to running, split into CI, Flux or Argo CD, and rollout, and the change failure rate of the week's deploys. Deploys are remembered on this Lens. A rollout that does not finish, a Flux or Argo CD apply that fails, a rollback, or a hotfix within a day counts as a failure.
+
 ## 0.1.0
 
 - The extension is named **GitLabOps** in the navigator, the status bar, and the settings.

package/README.md

@@ -30,9 +30,12 @@ The dashboard opens with a banner saying how the cluster stands: **Up to date**,
 - **Cards** for how many services run the latest commit, how many versions are running, and how many recent commits pass their pipelines.
 - **Services**: a table of every service the cluster runs from a build of the last 30 commits or releases, named after its image (such as `checkout-api`), with the version it runs and how many commits or releases behind the latest it is. Its **Deployed by** column names the Kustomization, HelmRelease or Argo CD Application that applies it, with its status and, for a HelmRelease, the chart version installed. When Flux has a newer chart, the status says so while it waits to install, is installing, or failed to install. When Flux image automation has picked up a newer build, the status follows it through Flux: **selected** by an ImagePolicy, **committed** to the GitOps repository by an ImageUpdateAutomation, **applying**, or **failed to apply**, then **rolling out**. Hover a service to see its workloads and what deploys them. Click a service to open its workload's details, and what deploys it to open its details.
 - **GitOps syncs**, for a branch a Flux GitRepository or an Argo CD Application of the cluster follows: a table of the Kustomizations and Applications applying it, with the commit each applied and a newer one on its way, fetched, being applied, or failed to apply (the message on hover). This is what a GitOps repository, which deploys manifests rather than images, is followed by: watch it like any branch. The host in the Git remote has to be the host of the watch, so `gitlab.com/group/app` is not taken for the same project on a GitLab you host yourself.
-- **Recent commits** or **Recent releases**: a table of the five latest, each with its message, its pipeline results (only the pipelines it started count: a merge request pipeline, a security scan or a DAST run recorded against the same commit is listed apart and counts for nothing; for a release with no pipelines of its own, as when a project builds on its default branch and tags afterwards, those of the commit it was tagged on, marked "on main") and the services of the cluster that run its build. Click a commit id or tag, or its pipeline results, to open its details in a panel that slides in over the dashboard: its message, author and date, with a link to GitLab; the services, Kustomizations and Argo CD Applications of the cluster at it; and its pipelines, each a card with a timeline of its jobs, how long each took and, for a failed one, why it failed, with links to the pipeline and to each job, and to re-run a failed pipeline's failed jobs, after confirming (this needs the GitLab CLI's account to be allowed to retry pipelines). Successful pipelines start folded. **Open in a tab** in the panel keeps the pipelines open in a tab of their own, next to the dashboard, with the end of a failed job's trace, errors and warnings marked; it goes on updating a pipeline in progress and comes back after Lens restarts.
+- **Environments**, when the same project is watched on more than one cluster: a column per cluster, ordered dev, then stage, then prod, with the commit or release that cluster runs. A cluster is placed by a word in its name (`dev`, `stage`, `staging`, `prod`, `production`, and the same for qa and uat). The column you opened is marked. When the project records deployments in GitLab (`environment:` in `.gitlab-ci.yml`), each environment is shown with the version GitLab last deployed and the version the cluster of the same name runs. **production** also matches a cluster that follows `main`, `master` or `prod`. **Drift** means the two disagree, such as GitLab on `v1.4` while the cluster still runs `v1.3`. Click **Drift** to open the commits and merge requests between those two.
+- **Recent commits** or **Recent releases**: a table of the five latest, each with its message, its pipeline results (only the pipelines it started count: a merge request pipeline, a security scan or a DAST run recorded against the same commit is listed apart and counts for nothing; for a release with no pipelines of its own, as when a project builds on its default branch and tags afterwards, those of the commit it was tagged on, marked "on main") and the services of the cluster that run its build. Click a commit id or tag, or its pipeline results, to open its details in a panel that slides in over the dashboard: its message, author and date, with a link to GitLab; the services, Kustomizations and Argo CD Applications of the cluster at it; and its pipelines, each a card with a timeline of its jobs, how long each took and, for a failed one, why it failed, with links to the pipeline and to each job. A failed pipeline can re-run its failed jobs after confirming. A job GitLab is waiting on (`when: manual`) has **Play**, which starts that job after confirming. Both need the GitLab CLI's account to be allowed to run jobs. Successful pipelines start folded. **Open in a tab** in the panel keeps the pipelines open in a tab of their own, next to the dashboard, with the end of a failed job's trace, errors and warnings marked; it goes on updating a pipeline in progress and comes back after Lens restarts.
 
-For a branch, a service is recognised by the commit id, in full or abbreviated to at least 7 characters, in its image's tag, as in `backend:main-76cd335`. For releases, by its image's tag being the release's tag, with or without a leading `v`, as in `backend:v2026.9.3-rc.1`. The cluster's Deployments, StatefulSets and DaemonSets are read, and Flux's Kustomizations, HelmReleases, ImagePolicies and ImageUpdateAutomations and Argo CD's Applications when the cluster has them. Opening the dashboard connects Lens to the cluster. If the cluster cannot be read, for instance while its connection is down, the dashboard says so and tries again every 30 seconds.
+For a branch, a service is recognised by the commit id, in full or abbreviated to at least 7 characters, in its image's tag, as in `backend:main-76cd335`. An image pinned by digest (`backend@sha256:…` or `backend:latest@sha256:…`) or tagged `latest` is recognised when the workload or its pod template carries `org.opencontainers.image.revision` for that commit, as an annotation or a label. For releases, by its image's tag being the release's tag, with or without a leading `v`, as in `backend:v2026.9.3-rc.1`. The cluster's Deployments, StatefulSets and DaemonSets are read, and Flux's Kustomizations, HelmReleases, ImagePolicies and ImageUpdateAutomations and Argo CD's Applications when the cluster has them. Opening the dashboard connects Lens to the cluster. If the cluster cannot be read, for instance while its connection is down, the dashboard says so and tries again every 30 seconds.
+
+**DORA**, under the project cards, is for one watched project on this cluster, chosen from the menu, as this Lens sees it. **Lead time** is the median time from a commit to it running, over the last 7 days. The latest deploy is split into where that time went: CI (commit until the pipeline it started finished), Flux or Argo CD (until that controller applied it), and rollout (until the workload was available). A GitOps sync that applies manifests and has no workload ends at apply. **Change failure rate** is how many of the week's deploys led to a problem: a rollout that hit its progress deadline, Flux or Argo CD failing to apply, a newer commit replaced by an older one, or a hotfix or revert committed within a day. Each deploy is remembered on this computer, so it is still there after the next one. ReplicaSets the cluster still keeps (Kubernetes keeps about 10) fill in a rollout that happened while Lens was closed; that time is when the ReplicaSet was created. These figures are from the Lens that was open to see them, not an organisation-wide DORA report.
 
 While the dashboard is open, the cluster is followed live, and GitLab is checked as often as there is something to see. While pipelines are unfinished, or a service is on its way through Flux or rolling out, it checks every 15 seconds (**live** in the header). Otherwise it checks once a minute whether a new commit has landed, and refreshes everything at the project's check interval. If GitLab's rate limit is reached, it waits for the check interval before trying again. The refresh button checks right away.