TLDR;
For CRs Workflows based on pull-requests, there is currently an inconsistency regarding how CRs already present at the base are treated. We're in the process of fixing this.
Details
In reviewdog there is already a built-in mechanism that exists that allows ignoring annotations & diagnostics when they are located on files not touched by the PR. We make use and rely on this, for example in comment-crs-in-pr.
For CRs specifically this is particularly relevant as this addresses the question of whether to consider a CR pre-existing at the base as belonging to the PR. This maps to a concept of the crs project which is called "active". A CR is active in a PR meaning work on it is intended to happen in this PR. You probably want any CR pre-existing at a given base revision to be not active in any new PR that is created from that base revision.
For other worklows that do not go through reviewdog currently there exists an inconsistency and limitation: all CRs parsed are active, regardless of their presence at the PR base.
We have prepared for the population of a cli argument --pull-request-base REV but currently it is not used.
This is an area of work in progress. We're in the process of making sure this flag is populated by the workflows, and we're working on a version of crs that'll make use of this - I'll come back to this issue when I have an update on this. Please comment if you'd like to discuss further.
TLDR;
For CRs Workflows based on pull-requests, there is currently an inconsistency regarding how CRs already present at the base are treated. We're in the process of fixing this.
Details
In
reviewdogthere is already a built-in mechanism that exists that allows ignoring annotations & diagnostics when they are located on files not touched by the PR. We make use and rely on this, for example incomment-crs-in-pr.For CRs specifically this is particularly relevant as this addresses the question of whether to consider a CR pre-existing at the base as belonging to the PR. This maps to a concept of the crs project which is called "active". A CR is active in a PR meaning work on it is intended to happen in this PR. You probably want any CR pre-existing at a given base revision to be not active in any new PR that is created from that base revision.
For other worklows that do not go through
reviewdogcurrently there exists an inconsistency and limitation: all CRs parsed are active, regardless of their presence at the PR base.We have prepared for the population of a cli argument
--pull-request-base REVbut currently it is not used.This is an area of work in progress. We're in the process of making sure this flag is populated by the workflows, and we're working on a version of crs that'll make use of this - I'll come back to this issue when I have an update on this. Please comment if you'd like to discuss further.