Trigger resolve_dependency_bump DAP workflow on dep-bump MR pipeline failure

Hitesh Raghuvanshirequested to merge
600727-trigger-dep-bump-resolution-on-enabler into master

What does this MR do and why?

Adds a trigger that automatically starts the existing resolve_dependency_bump/experimental DAP foundational flow when a dependency-bump MR pipeline fails.

The new worker DependencyManagement::SecurityUpdate::TriggerResolveDependencyBumpWorkflowWorker subscribes to Ci::PipelineFinishedEvent and, on failure of a dependency-bump MR's pipeline, kicks off the AI workflow via Ai::Catalog::Flows::ExecuteService (mirroring the secret detection FP pattern).

Gated by the existing enable_dependency_bump_breaking_changes beta flag (checked on the project's root ancestor), together with the duo_dependency_bump_breaking_changes project setting and the foundational-flow checks — all bundled in Project#duo_dependency_bump_breaking_changes_available?. No separate experiment flag is introduced.

Detection signal

  • pipeline.status == 'failed'
  • the pipeline has an open merge request, resolved via pipeline.all_merge_requests.opened (matched by commit SHA, so both merge-request and branch pipelines are covered)
  • that MR is authored by the dependency-management service account (a service_account user named GitLab Dependency Management), matched in SQL via the authored_by_dependency_bump_service_account scope

Whose identity the workflow runs as

The workflow runs as the user who enabled the duo_dependency_bump_breaking_changes setting, tracked via duo_dependency_bump_breaking_changes_enabled_by (added in !243449 (merged)) — not first_owner, which would be a security issue.

Fail closed: if that enabler is missing (e.g. the account was deleted, so enabled_by_id was nulled by the FK) or is no longer authorized to execute the flow (:duo_workflow), the worker disables the duo_dependency_bump_breaking_changes setting and does not trigger the workflow — stopping it from re-triggering on every failed pipeline.

Safety guards (worker-side)

  • Availability check (duo_dependency_bump_breaking_changes_available?): enable_dependency_bump_breaking_changes beta flag (root ancestor) + duo_dependency_bump_breaking_changes project setting + foundational flow enabled
  • In-flight check: skip if any non-terminal workflow already exists for the MR
  • Iteration cap: skip if 2 workflows have already been started for the MR
  • No consumer: log info and no-op if the project hasn't enabled the foundational flow
  • Enabler missing / unauthorized: disable the setting and no-op

How to set up and validate locally

  1. Use an Ultimate project with Duo Agent Platform available and the resolve_dependency_bump/experimental foundational flow enabled (so Project#duo_dependency_bump_breaking_changes_available? returns true).
  2. Enable the beta flag on the root ancestor: 
    Feature.enable(:enable_dependency_bump_breaking_changes, project.root_ancestor)
  3. Enable the setting and record an enabler who has :duo_workflow on the project: 
    project.project_setting.update!(
  duo_dependency_bump_breaking_changes_enabled: true,
  duo_dependency_bump_breaking_changes_enabled_by: enabler_user
)
  4. Provision the dependency-management service account: 
    DependencyManagement::ProvisionServiceAccountService.new(project: project).execute
# creates the "GitLab Dependency Management" service account
  5. Open a dependency-bump MR authored by that service account that changes package.json / package-lock.json and whose pipeline fails. (Works for both merge-request and branch pipelines.)
  6. Once the pipeline fails, confirm the workflow was triggered: 
    Ai::DuoWorkflows::Workflow.where(merge_request_id: merge_request.id)
# => one record: workflow_definition "resolve_dependency_bump/experimental",
#    user = the enabler, merge_request_id populated

Validating fail-closed behavior

  • Null the enabler while the setting is on (simulates a deleted enabler), then fail a pipeline — the setting is disabled and no workflow is created: 
    project.project_setting.update!(duo_dependency_bump_breaking_changes_enabled_by_id: nil)
  • Or set an enabler without :duo_workflow on the project — same fail-closed disable.

References

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist.

Edited by Hitesh Raghuvanshi

Merge request reports