Conversation
78df0f7 to
516d81c
Compare
| LOG.warn("Execution of Pylint is deprecated and will be removed." + | ||
| " Instead, Pylint should be executed before sonar-scanner and its report should be imported using the '" + PylintImportSensor.REPORT_PATH_KEY + "' property."); |
There was a problem hiding this comment.
What happens if a user was still relying on pylint execution mode? The user would lose issues and would maybe not understand why (maybe his/her SonarQube administrator updated sonar-python-plugin without notice).
Should we log a warning when we detect that some properties like sonar.python.pylint or sonar.python.pylint_config are set? That's just an idea and it's far from perfect: as such properties had default values, there may be cases where people use pylint execution mode without setting those properties.
There was a problem hiding this comment.
After discussion with Alex, we agreed that it's not needed as we have displayed a deprecation warning for quite some time now.
| .onQualifiers(Qualifiers.PROJECT) | ||
| .multiValues(true) | ||
| .build(), | ||
| PylintRulesDefinition.class); |
There was a problem hiding this comment.
Very minor: it's weird to have PylintRulesDefinition here and PylintSensor in a separate call to context.addExtension.
| protected static final Pattern DEFAULT_PATTERN = Pattern.compile("(.+):(\\d+):(\\d+): (\\S+[^:]):? (.*)"); | ||
| protected static final Pattern LEGACY_PATTERN = Pattern.compile("(.+):(\\d+): \\[(.*)\\] (.*)"); |
| return null; | ||
| } | ||
|
|
||
| private static Issue extractDefaultStyleIssue(Matcher m, int columnOffset) { |
There was a problem hiding this comment.
Do we need to have columnOffset as a parameter? Can't we read this.reportOffset?
| protected void importReport(File reportPath, SensorContext context, Set<String> unresolvedInputFiles) throws IOException, ParseException { | ||
| InputStream in = new FileInputStream(reportPath); | ||
| LOG.info("Importing {}", reportPath); | ||
| boolean engineIdIsSupported = context.getSonarQubeVersion().isGreaterThanOrEqual(Version.create(7, 4)); |
There was a problem hiding this comment.
Do we still need to support SQ 7.4? Maybe we can change that in a separate PR.
There was a problem hiding this comment.
Indeed, I had in mind to have a small clean-up PR afterwards to freshen a bit BanditSensor among other things, didn't want to mix that with that with the actual implementation for ease of reviewing.
| "key": "C0111", | ||
| "name": "Missing docstring", | ||
| "priority": "MINOR", | ||
| "status": "DEPRECATED" |
There was a problem hiding this comment.
I think we shouldn't set this deprecation status.
As far as I know, the original motivation was to reimplement pylint rules and to mark the pylint rules we had reimplemented as deprecated. I don't think it makes sense in the context of external issues.
| String filePath = m.group(1); | ||
| int lineNumber = Integer.parseInt(m.group(2)); | ||
| String ruleKey = m.group(3); | ||
| int lastIndex = Math.min(ruleKey.indexOf(","), ruleKey.indexOf("(")); |
There was a problem hiding this comment.
Do we need ruleKey.indexOf(",")? Do we have a test case to cover it?
There was a problem hiding this comment.
I thought I saw such format somewhere, but impossible to find it again...I'll remove this.
| @Test | ||
| public void no_issues_unknown_files() throws IOException { | ||
| List<ExternalIssue> externalIssues = executeSensorImporting(7, 9, "pylint_report_unknown_files.txt"); | ||
| assertThat(externalIssues).isEmpty(); |
There was a problem hiding this comment.
Should we assert anything about the logs?
| // Only for PylintSensor | ||
| return reportPathKey().equals(PylintSensor.REPORT_PATH_KEY) && | ||
| conf.hasKey(PYLINT_LEGACY_KEY); |
There was a problem hiding this comment.
Alternative solution: rely on polymorphism and define this condition in PylintSensor.
f09161a to
99b6f15
Compare
16f5e7f to
3083c9a
Compare
3083c9a to
4817dcd
Compare
|
Kudos, SonarQube Quality Gate passed!
|
GitOrigin-RevId: 2136b155a91f9acf77c7ef0b3d9fbda7d5fee260
No description provided.