Skip to content

Add parallel persistence for author_name on AuditEvent

What does this MR do?

As part of the wider AuditEvent refactoring, it does the following:

  • Creates a new database column (author_name) on AuditEvent.
  • Reroutes author_name to be stored in both the new column and the existing details hash.
  • Updates specs to take this in to account
  • Reads from the new database column by default, and falls back to the details hash for older records.

Does this MR meet the acceptance criteria?

Conformity

Database Review

Migration

== 20200623090030 AddAuthorNameToAuditEvent: migrating ========================
-- column_exists?(:audit_events, :author_name)
   -> 0.0010s
-- add_column(:audit_events, :author_name, :text)
   -> 0.0003s
-- transaction_open?()
   -> 0.0000s
-- execute("ALTER TABLE audit_events\nADD CONSTRAINT check_83ff8406e2\nCHECK ( char_length(author_name) <= 255 )\nNOT VALID;\n")
   -> 0.0003s
-- execute("ALTER TABLE audit_events VALIDATE CONSTRAINT check_83ff8406e2;")
   -> 0.0736s
== 20200623090030 AddAuthorNameToAuditEvent: migrated (0.0781s) ===============

Rollback

== 20200623090030 AddAuthorNameToAuditEvent: reverting ========================
-- remove_column(:audit_events, :author_name)
   -> 0.0013s
== 20200623090030 AddAuthorNameToAuditEvent: reverted (0.0014s) ===============

Availability and Testing

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

  • Label as security and @ mention @gitlab-com/gl-security/appsec
  • The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
  • Security reports checked/validated by a reviewer from the AppSec team

Mentions #220318 (closed)

Edited by Jan Provaznik

Merge request reports