Stop persisting CI warnings for successful pipelines

Oleg Yakovenkorequested to merge
521902-skip-config-warnings-on-pipeline-creation into master

What does this MR do and why?

CI config warnings are stored in ci_pipeline_messages, one row per warning per pipeline. The table grows fast and is now a database capacity concern. Nothing reads the stored rows: the pipeline page does not show them, and the GraphQL Pipeline.warningMessages field's only frontend consumer (the Run pipeline form) can never receive them. CI Lint and the pipeline editor read warnings from a pipeline object that is never saved.

This MR:

  1. Builds warnings outside the pipeline messages association and keeps them in memory. They are never saved, on success or failure. Ci::Pipeline#warning_messages reads that in-memory list, so CI Lint, the pipeline editor, and the pipeline creation API response keep working.
  2. Restores the retry:when deprecation warning for stuck_or_timeout_failure and job_execution_timeout that !250922 (merged) removed. This is safe now that warnings never reach the database. Users see it in CI Lint and the pipeline editor.

Two warnings are affected: the retry:when one, and the older "may allow multiple pipelines to run for a single action due to rules:when" warning, which is most of the existing rows. Neither warning is deleted.

Why errors stay and warnings go

Errors in the same table have real readers: the pipeline page and the pipeline header badge. The product is also moving off the old pipeline.yaml_errors column onto this table. Warnings never got a reader: warningMessages was added in 14.8 by #350276 (closed) for a pipeline page banner that was never built.

Tradeoff: the GraphQL warningMessages field

This changes the behaviour of a public API field. Pipeline.warningMessages is not removed, but it returns nothing for pipelines created after this ships. Rows saved before the change are still returned.

  • No frontend code is affected. The only frontend consumer could never display the data.
  • Real usage on GitLab.com is a handful of queries per day, fewer than 1000 requests over the last 30 days (logs).

The field is not deprecated, since removal is not decided. Its description now says it is not populated for newly created pipelines, so the GraphQL reference explains the empty result.

No feature flag

The change is behind feature flag::skipped. Nothing reads the rows it stops writing, so there is no behaviour to roll out gradually, and a revert is a single commit that restores the previous writes.

How to test

  1. Add a job with retry: { max: 2, when: stuck_or_timeout_failure }.
  2. Run a pipeline and confirm it runs.
  3. Confirm Ci::PipelineMessage.where(pipeline_id: <id>) has no warning row.
  4. Paste the same config into CI Lint and confirm the deprecation warning shows.

References

Edited by Oleg Yakovenko

Merge request reports