Skip to content

Collect release evidence at release timestamp

What does this MR do?

When a Release is created, determine if it is a Release, an Upcoming Release or a Historical Release. Passing the released_at field to the API is the deciding factor.

The existing after_commit hook on Release will be removed, and instead the CreateEvidenceWorker call will be made in the API controller, after the Release object is successfully created.

after_commit :create_evidence!, on: :create, unless: :importing?

https://gitlab.com/gitlab-org/gitlab/blob/master/lib/api/releases.rb#L68-70

Current Release

If the released_at field is not passed, it is defaulted to the current timestamp and the Evidence is created. The CreateEvidenceWorker will be scheduled as perform_async.

Upcoming Release

If a future released_at timestamp is provided via the API, the CreateEvidenceWorker will be scheduled for the future timestamp using the Sidekiq Scheduled Jobs feature, noting that it may not run exactly at the provided released_at timestamp.

Historical Release

If the released_at timestamp is provided and is in the past, an Evidence object will not be provided for this release.

Screenshots

Upcoming Releases are indicated as such, until the released_at date passes. This is already implemented and not added by this MR.

Screenshot_2020-01-27_at_12.34.02

Does this MR meet the acceptance criteria?

Conformity

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

Part of #38103 (closed)

Edited by Sean Carroll

Merge request reports