Fire first_pipeline_succeeded internal event on first successful pipeline

Sahil Sharmarequested to merge
ss/594029-ttfp-internal-event-firing into master

What does this MR do and why?

Adds instrumentation to track when a project's first CI pipeline succeeds. This supports the Time-to-First-Pipeline (TTFP) metric for the AI Pipeline Builder feature, which is part of the North Star metrics tracked in #594029.

When a pipeline transitions to success, a new Ci::TrackFirstPipelineSucceededWorker fires asynchronously. The worker performs an INSERT ... ON CONFLICT DO NOTHING upsert into ci_project_metrics. If the insert lands (first success for that project), it fires the first_pipeline_succeeded internal event with the TTFP value in seconds (time between project creation and now). Subsequent pipeline successes hit the conflict path and skip the event, keeping the instrumentation idempotent.

Relates to #594029

Database

Table: ci_project_metrics (schema: gitlab_ci, created in a prior MR in this series).

Raw SQL

INSERT INTO ci_project_metrics (project_id, first_pipeline_succeeded_at, created_at, updated_at)
VALUES ($1, $2, $3, $4)
ON CONFLICT (project_id) DO NOTHING
RETURNING "id"

Query plan

https://console.postgres.ai/gitlab/gitlab-production-ci/sessions/50982/commands/150953

How to set up and validate locally

  1. Start GDK.
  2. Start the internal events monitor: 
    rails runner scripts/internal_events/monitor.rb first_pipeline_succeeded
  3. Create a new project (or use one with no prior successful pipelines).
  4. Add a .gitlab-ci.yml and push to trigger a pipeline.
  5. When the pipeline succeeds, verify:
    • first_pipeline_succeeded appears in the monitor output with the TTFP value in seconds.
    • Ci::ProjectMetric.find_by(project_id: project.id) exists and has first_pipeline_succeeded_at set.
  6. Trigger a second successful pipeline on the same project. The worker runs but does NOT fire the event again, confirming idempotency. No new output should appear in the monitor.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

https://docs.gitlab.com/ee/development/code_review.html#acceptance-checklist

Edited by Sahil Sharma

Merge request reports