Closed convenient closed 1 year ago
@hostep @sprankhub I think this is it, there's probably room for improvement as we get some real world experience of how these checks come through but would be curious to see if you have any rough thoughts.
@peterjaap FYI new WARN
type, and the introduction of IGNR
which is hidden by default and probably does not need reported in your tool.
Great job! Awesome work!!
Just gave it a try on a extremely customised project that we're currently upgrading from 2.3.6 to 2.4.6. And it only warns about 312 files instead of 328 files before. The 16 files it marks to be ignored all seem to be correct and are:
Just one thing I'm missing is the mention of this new --show-ignore
flag in the README file, I see it's documented in that CHECKS_AVAILABLE.md file, but a mention on the main README file can't harm here I think.
Again, awesome job! 👏
Good catch on the README.md
I have updated that now.
Thanks for the real world example @hostep that looks good to me :)
Sorry for taking ~5 years to solve #13 but at least it's here now 😆
This PR attempts to solve the following, both of these combined should allow you to do less work, and the work you do have to do should be more targeted
13
85
Both of those issues require some understanding of what is "meaningful", so the start of that is stripping of whitespace/comments/multi newlines.
With the ability to understand what the actual change made in vendor looks like, we can hopefully ignore a lot of redundant checks. And in the event that the overridden file is now redundant itself, report that.
In this PR I have scaffolded the rough setup of how I think this can work, as well as some test cases for
.html
template overrides. I will link subsequent PRs pointing to this branch as I implement each check type just to try and keep it easier to review and grok what i'm doing. For example of each type and what can be ignored or flagged as redundant click throughI have added a new type called
IGNR
which is visible with--show-ignore
, this is because I don't want to risk binning off anything that was previously highlighted and this way we can still investigate just in case there is a bug or something.I see three types of cases
Case 1 - Current base functionality
WARN
, needs review as standardCase 2 - A NOOP change (comment/whitespace/etc)
IGNR
as it's something to be filtered (hidden until ran with--show-ignore
)Case 3 - Changed to match the override, maybe the override was backported but no longer necessary
WARN
, its a redundant overrideUpdated documentation can be seen
There's a lot of moving pieces and a bunch of test code required here which makes this PR quite chunky at 93, but looking at results may be the best way to get a sense of what is achieved here.
Checklist