<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=606520) </details> <!--IssueSummary end--> ## Summary `Deployment#update_merge_request_metrics!` only sets `first_deployed_to_production_at` on a merge request when the deployment's `ref` matches the MR's `target_branch`. When a project uses a **tag-based deployment workflow** (e.g., a tag `v0.68.0` is cut from `main` and the production deploy jobs live in the tag pipeline, not the branch pipeline), the deployment `ref` is the tag name, which never matches the MR target branch (`main`). As a result: - `first_deployed_to_production_at` remains `null` for all MRs deployed via tags. - The **Value Stream Analytics (VSA) Deploy stage** (configured as _Merge request merged → Merge request first deployed to production_) excludes those MRs entirely, even though valid production-tier deployments exist. - DORA deployment frequency metrics for the same environments are populated correctly, creating a confusing inconsistency. This affects any project that follows the common GitLab pattern of deploying to production from a tag pipeline rather than directly from a branch pipeline. --- ## Steps to Reproduce 1. Create a project with a `main` branch. 2. Configure a CI/CD pipeline so that: - The **branch pipeline** (for `main`) runs tests and builds but does **not** deploy to production. - A **tag pipeline** (e.g., triggered by pushing `v*` tags) contains the production deploy job targeting an environment with `deployment_tier: production`. 3. Create and merge a merge request targeting `main`. 4. Push a tag (e.g., `v1.0.0`) from `main`. The tag pipeline runs and successfully deploys to the production-tier environment. 5. Check the MR via the REST API: ``` GET /api/v4/projects/:id/merge_requests/:iid ``` 6. Observe that `first_deployed_to_production_at` is `null`. 7. Navigate to a group-level Value Stream Analytics page with a Deploy stage configured as _Merge request merged → Merge request first deployed to production_. 8. Observe that the MR does **not** appear in the Deploy stage, even though the production environment shows a successful deployment. --- ## Current Behavior - `Deployment#update_merge_request_metrics!` (see `app/models/deployment.rb`) queries for MRs where `target_branch = deployment.ref`. - When the deployment is from a tag (e.g., `ref = "v0.68.0"`), no MR has `target_branch = "v0.68.0"`, so no MR metrics are updated. - `first_deployed_to_production_at` stays `null` for all MRs whose production deployments are tag-driven. - The VSA Deploy stage end event (_Merge request first deployed to production_) depends on `first_deployed_to_production_at`, so those MRs are invisible in VSA Deploy stage metrics. - DORA deployment metrics for the same environments **are** correctly populated (they do not rely on the `ref`/`target_branch` match), creating a visible inconsistency. --- ## Expected Behavior - When a successful deployment to a production-tier environment is made from a **tag** pipeline, GitLab should identify MRs whose commits are included in that tag (e.g., by tracing the tag's commit SHA back to merged MRs targeting the relevant branch) and populate `first_deployed_to_production_at` accordingly. - The VSA Deploy stage should include those MRs, consistent with how DORA metrics already handle tag-based deployments. - Tag-based production deployments are a first-class, documented GitLab workflow (e.g., `only: tags`, protected tags for production gates) and should be treated equivalently to branch-based deployments for MR metrics and VSA. --- ## Environment - **GitLab.com** (SaaS, Ultimate tier) - **GitLab version:** GitLab.com (current) - **Deployment type:** GitLab.com SaaS --- ## Relevant Code - [`Deployment#update_merge_request_metrics!`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/deployment.rb) — the `target_branch == ref` condition is the root cause. - [`Deployments::UpdateEnvironmentService#update_environment`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/deployments/update_environment_service.rb) — orchestrates the metrics update. - `Deployments::UpdateEnvironmentWorker` — triggers the above on deployment success. --- ## Impact - **Analytics accuracy:** VSA Deploy-stage metrics under-report lead time for changes for any project using tag-based production deployments. - **Customer trust:** Teams cannot rely on VSA Deploy-stage data for these projects, undermining their ability to measure DORA lead time for changes across their value stream. - **Scope:** Affects all GitLab tiers and deployment types where tag pipelines are used for production deployments — a common, recommended pattern. --- ## Related Issues - [#538310](https://gitlab.com/gitlab-org/gitlab/-/issues/538310) — _Merge request metrics incorrect when manual jobs from multiple branches deploy to the same environment_ — related but distinct root cause (multi-branch manual job race condition vs. tag `ref` mismatch). The fix proposed in that issue (Option 1: filter `previous_deployment` by same `ref`) would **not** fix this issue, because here there is no MR with `target_branch` matching the tag ref at all. --- ## Questions for Engineering 1. Is it **intended** that `first_deployed_to_production_at` is only populated when `deployment.ref == mr.target_branch`, effectively excluding all tag-based production deployments? 2. If unintended, what is the preferred fix? - **Option A:** When a tag deployment succeeds, resolve the tag to its commit SHA and find MRs merged into the branch that the tag was created from (e.g., via `git log` ancestry or the existing `deployment_merge_requests` join table). - **Option B:** Use the `deployment_merge_requests` association (already populated for tag pipelines via commit inclusion) to drive `update_merge_request_metrics!` instead of the `target_branch == ref` query. 3. Should this be documented as a known limitation in VSA / deployment metrics docs until a fix is available?