Credo.Check format_issue opts allow a custom category #1165
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What am I doing?
Introducing support for a custom
category
option in theformat_issue
function, so we can overwrite the category given by Credo.Checkuse
spec.Why?
This allows defining specific categories as part of the same Credo.Check, which it can be useful for uses cases where the "searching" algorithm is used for related checks, but with different categories and/or notification levels. For instance, a Credo.Check (*1) I have been implementing recently: it searches for soft-deprecated and forbidden functions (while having
--warning-as-error
enabled in our CI pipelines, so@deprecated
cannot be used for soft ones)::soft_deprecated
,recommendation
,advice
, etc), and does not block CI pipelines (exit status 0). It can suggest alternative functions (when provided), and the owners of that region of code can update whenever they have time. Soft-deprecating functions take time to update all usages, and in most cases it requires cross-squad efforts, so, better to warn without failing and leave enough time for the developers to update their code (and even indirect usages, like external services that depend on the original functions, like grafana, datadog, new relic, etc).By combining these checks under one implementation, we optimize performance and reduce code duplication, as 90% of the logic is shared. However, the checks remain distinct in their categories and purposes, balancing performance and maintainability against separation of concerns and clarity.
Original proposal and context in this PR that fixes the exit_status.
Let me know if further refinements are needed!
*1 Note: Let me know if you would be interested in that Credo.Check and having it as one of the default ones in credo. I will need more time to have it polished and as fast as possible, but I'll happy to do so this winter - early 2025 ;)