Improve process for revoking a GitLab Runner release
Background
- Today, no formal process is defined to revoke a release of GitLab Runner for cases where that release has introduced a regression that breaks core functionality.
Proposal
- Define and document a formal process for revoking a release of GitLab Runner.
- The process needs to include a method to notify the user and customer community that a GitLab Runner release has introduced a regression.
Process draft
The proposed process steps below are for scenarios where a regression in a GitLab Runner release breaks core functionality. This process assumes that the regression was not identified during our internal pre-release testing.
-
Remove the packages for the affected release from packages.gitlab.com -
Remove the packages for the affected release from hub.docker.com -
Delete files for the affected release from AWS S3 bucket. -
Notify users that may have downloaded the affected release (not sure yet how to do that). -
Communicate via some mechanism that gitlab-runner release x.xx has an issue and packages have been revoked. (blog post, release post entry.) Our goal here is to ensure that we get the information to the community as soon as possible.
Edited by Darren Eastman