Incident Timeline Quick Actions

Release Post

Every second counts when users are working to resolve an incident. With GitLab 15.4 users can now use quick actions to add events to the incident timeline. Users can backfill multiple timeline events, using quick actions to avoid spending valuable time entering timeline events in the user interface. In any incident comment, add `/timeline comment | YYYY-MM-DD' or leave the date blank to default to now.

https://docs.gitlab.com/ee/user/project/quick_actions.html#gitlab-quick-actions

Problem to Solve

The Infrastructure Team currently uses free-form text to fill in an incident timeline on GitLab incidents using the incident template

The Incident timeline could replace the timeline section that is currently being used.

The main obstacle to Incident Timelines is the ability to backfill multiple timeline events, and doing this through the UI will probably be a bit cumbersome and time consuming. We also programmatically need to add a timeline event, specifically the first one which is who declared the incident since the issue is opened using the API (via Slack) by a bot user.

Proposal

One possible solution to this is to add a quick action would make using the timeline feature feasible as a replacement for our free-form Timeline description, by both allowing the ability to create a timeline item programmatically by sending the quick action when we create the issue using the API and also adding timeline items in bulk, example:

<timeline comment> | <date(YYYY-MM-DD> time<HH:MM>

...which would look something like this, in practice:

/`timeline @someuser updates feature flag to true | 2022-06-10 09:30`
/`timeline status page updated`
/`timeline new deploy to resolve issu` | 11:00`
/`timeline deploy finished | 12:30`

Considerations

1. Smart parsing of the timestamp, by default we use the current time, or the current day unless specified.
2. Assume time is in UTC.
3. The time format should include the date time, i.e. 2022-06-10 09:30
4. We sometimes fill in timelines on behalf of other people, we could put the user in the timeline text but maybe you could override the username associated with the event somehow
5. Having a quick action is probably good enough as an API substitute, for example when an incident is updated we execute a webhook that could fill in the timeline automatically in some cases, by issuing a note with the quick action.