Skip to content

Suppressions as a checked in resource do not make sense #75

Open
@tjprescott

Description

@tjprescott

Suppressions were introduced here (#47). The goal behind having a yaml file is that you could add point suppressions with a rationale, and these point suppressions would be approved as part of the PR by the relevant approvers.

This model has some fundamental flaws, because once the PR is approved, that suppression file will be checked in as an artifact.

Fundamentally, the suppressions only matter between two specific versions of the API. If you suppress something going from version 1 to 2, when you go to version 3, if that item is unchanged from version 2 you have no diff and the suppression does nothing. However, if you DO change something between version 2 and 3, you very likely want to re-review it, but the suppression will suppress the change and allow it in!

So fundamentally, we would need to rethink how this feature works.

Metadata

Metadata

Assignees

No one assigned

    Labels

    designissues related to the design of the tool itself

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions