Skip to content

Dont force creation of Ci::NamespaceMirror during test runs

What does this MR do and why?

  • Change namespace.create_ci_namespace_mirror! to namespace.create_ci_namespace_mirror
  • Update Data Seeder documentation

Closes #451907 (closed)

Reasoning

When using the Data Seeder to seed data into a GitLab instance, a PG::UniqueViolation: ERROR: duplicate key value violates unique constraint "index_ci_namespace_mirrors_on_namespace_id" is often hit. This UniqueViolation error is caused from competing logic from the spec/factories/namespaces.rb factory and the Namespaces::ProcessSyncEventsWorker. The factory is attempting to create the namespace mirror despite the worker already creating it. The guard clause unless namespace.ci_namespace_mirror is not guarding against this because of timing, which would explain the flakiness.

According to the Active Record Associations documentation:

create_association

This object will be instantiated from the passed attributes, the link through its foreign key will be set, and, once it passes all of the validations specified on the associated model, the associated object will be saved.

create_association!

Does the same as create_association above, but raises ActiveRecord::RecordInvalid if the record is invalid.

This change will remove the bang ! to not necessarily care if the mirror is not created (i.e., it is already created by the worker). See this comment as to why this simulation is present to begin with. Since Data Seeder usually targets live environments, these instances do indeed run Sidekiq inline, thus this logic is competing.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before After

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

Edited by Dan Davison

Merge request reports

Loading