Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Invalid severity type for Code Climate export format #5349

Closed
6 of 7 tasks
loozhengyuan opened this issue Jan 27, 2025 · 5 comments · Fixed by #5350
Closed
6 of 7 tasks

Invalid severity type for Code Climate export format #5349

loozhengyuan opened this issue Jan 27, 2025 · 5 comments · Fixed by #5350
Labels
area: output Related to issue output bug Something isn't working

Comments

@loozhengyuan
Copy link

loozhengyuan commented Jan 27, 2025

Welcome

  • Yes, I'm using a binary release within 2 latest releases. Only such installations are supported.
  • Yes, I've searched similar issues on GitHub and didn't find any.
  • Yes, I've read the typecheck section of the FAQ.
  • Yes, I've tried with the standalone linter if available (e.g., gocritic, go vet, etc.).
  • I agree to follow this project's Code of Conduct

Description of the problem

Using the code-climate export format, there may be instances where the exported file does not have the correct severity type as defined by the Code Climate severity types:

[
  {
    "description": "gosec: G114: Use of net/http serve function that has no support for setting timeouts",
    "check_name": "gosec",
    "severity": "medium",
    "fingerprint": "4909C824372D1A973F00BF10084672E6",
    "location": { "path": "http.go", "lines": { "begin": 22 } }
  },
  {
    "description": "revive: unused-parameter: parameter 'r' seems to be unused, consider removing or renaming it as _",
    "check_name": "revive",
    "severity": "warning",
    "fingerprint": "D93243590B7D6E9AACE104BCD6F2737B",
    "location": { "path": "http.go", "lines": { "begin": 12 } }
  }
]

Looking at Code Climate printer in the code base, it seems that the severity is emitted as-is when in fact there may be some mapping we could have done.

Version of golangci-lint

$ golangci-lint --version
golangci-lint has version v1.63.4 built with go1.23.2 from (unknown, modified: ?, mod sum: \"h1:bJQFQ3hSfUto597dkL7ipDzOxsGEpiWdLiZ359OWOBI=\") on (unknown)

Configuration

$ golangci-lint run --verbose --print-issued-lines=false --out-format code-climate:golangci-lint.json,line-number

Go environment

$ go version && go env
go version go1.23.2 linux/amd64

Validation

  • Yes, I've included all information above (version, config, etc.).

Supporter

@loozhengyuan loozhengyuan added the bug Something isn't working label Jan 27, 2025
Copy link

boring-cyborg bot commented Jan 27, 2025

Hey, thank you for opening your first Issue ! 🙂 If you would like to contribute we have a guide for contributors.

@ldez ldez removed the bug Something isn't working label Jan 27, 2025
@ldez
Copy link
Member

ldez commented Jan 27, 2025

Hello,

you should apply your mapping of severities through the configuration: https://golangci-lint.run/usage/configuration/#severity-configuration

I will create a PR to reject non-allowed severity names.

We will not embed a mapping.

@ldez ldez added question Further information is requested area: output Related to issue output labels Jan 27, 2025
@ldez ldez added bug Something isn't working and removed question Further information is requested labels Jan 27, 2025
@loozhengyuan
Copy link
Author

@ldez Thanks for looking into this issue and making quick changes!

However, I think (do correct me if I am wrong) the severity configuration does not address the need because it blankets the severity for all rules in the linter. For example, if gosec had 2 violating checks with low and medium severity, it would be ideal if we can map this value to something minor and major, instead of assigning a blanket severity of all checks.

I can understand that embedding severity mappings can be problematic because it can be up to one's interpretation. Wondering if, perhaps, we could expose configuration options to map severity for this use-case? For example:

severity:
  rewrite:
    low: "info"
    medium: "minor"
    high: "major"
    warning: "error"
    error: "blocker"

@ldez
Copy link
Member

ldez commented Jan 27, 2025

I created a local implementation, but currently, I prefer to limit new elements during the work on v2. #5300

Your idea will be used, but after the work on v2.

@loozhengyuan
Copy link
Author

Cool, many thanks for your consideration!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: output Related to issue output bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants