Create process for fixing bugs in sast-rules
Proposal
As explained in this comment, we don't have a formal process for fixing priority1 bugs in sast-rules
, which slows down bug fixes and can lead to really confusing situations.
In order to avoid this from happening in the future, we should document a formal process for quickly fixing bugs in sast-rules
, which is the purpose of this issue.
Possible solutions
When a bug is discovered, we can create a branch in sast-rules
which points to the most recent tag, for example say v2.5.1 is the most recent release of sast-rules
. We would create a branch in sast-rules
called v2.5.1-bugfix
which fixes the bug and bumps the changelog version to v2.5.2
, then release this as sast-rules v2.5.2
. We can then update the semgrep Dockerfile to point to the new sast-rules v2.5.2
with the bugfix.
The changelog in the main
branch of sast-rules
will still show v2.5.1
as the most recent entry, so we need to make sure that we merge the changes from v2.5.1-bugfix
into the main
branch before we release any other changes in the main
branch. We should programmatically prevent new releases from happening until the bugfix is merged into the main
branch.
Implementation Plan
See Draft: Document bugfix process (gitlab-org/security-products/sast-rules!632) • Adam Cohen as a starting MR for implementing the following:
-
Create a new bugfix
protected branch in sast-rules.Done: https://gitlab.com/gitlab-org/security-products/sast-rules/-/tree/bugfix
-
Add logic to the release_job job to prevent new code from being released when a bugfix
is in progress. -
Document how to create a bugfix
. -
Document how to merge the bugfix
branch into themain
branch.
/cc @julianthome @craigmsmith @tkopel @theoretick @dbolkensteyn