Skip to content

Implement customizable CA events

Adam Hegyi requested to merge 12196-additional-ca-events into master

What does this MR do?

This change defines additional events for creating customized cycle analytics stages.

How to Review

This MR seems quite big, however it's mostly "glue" code. We extend FOSS code, so additional context is needed for the review. I'd suggest to do the review in the following order:

  1. Read the description.
  2. See the current (FOSS) implementation of StageEvents: https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/analytics/cycle_analytics/stage_events.rb
    1. What kind of Events we have.
    2. How do we express pairing rules.
  3. Look at the MR code, start with ee/lib/ee/gitlab/analytics/cycle_analytics/stage_events.rb
    1. StageEvents is a module, so extending it (overriding methods) is a bit trickier.
  4. Look at the event implementations: ee/lib/gitlab/analytics/cycle_analytics/stage_events/*
  5. Event tests: ee/spec/lib/gitlab/analytics/cycle_analytics/stage_events/*
  6. Test start and end events in "integration": ee/spec/lib/gitlab/analytics/cycle_analytics/data_collector_spec.rb
    1. There are a many possible combinations, I made sure to use every event class at least once.

What is Cycle Analytics

  • Related issue: https://gitlab.com/gitlab-org/gitlab-ee/issues/12196
  • Find all the Issue or MergeRequest records matching with a date range query (start_event and end_event) = Stage.
  • Calculate the duration (end_event_time - start_event_time) (already implemented and merged)
  • Extract the median duration. (already implemented and merged)
  • Extract the list of records relevant to the date range. (already implemented and merged)
  • In EE, cycle analytics stages will be customizable, you can define your own event pairs.

How it Works

An event is a simple ruby class with the following methods:

  • name: name of the event
  • identifier: internally used identifier for the event
  • object_type: what kind of resource this event belongs to (IssueCreated => Issue)
  • timestamp_projection: SQL expression or column to calculate the duration. (DURATION = end_event_time - start_event_time)
  • More info about event classes: https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/analytics/cycle_analytics/stage_events/stage_event.rb
  • Since some events are not compatible with each other, we have a mapping (see pairing_rules method) that defines which event pairings are possible.
    • Example: Issue Closed - Issue Created pairing makes no sense, because it would produce negative duration.
  • Currently supported pairings (origin: start event, arrow: possible end event)

pairing_rules

(I'm planning to create a dev docs about this feature)

Screenshots

Users can define the stages and select events (right side):

https://gitlab.com/gitlab-org/gitlab/uploads/d4280665724e914514e1217b56e80a5a/ca-custom-stages__add--start-event.png

To avoid selecting "wrong" events, the FE will only show allowed pairs.

Does this MR meet the acceptance criteria?

Conformity

Performance 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
Edited by Dan Jensen

Merge request reports