Credo.Check format_issue can use a custom exit_status option

[rNoz]

What am I doing?

Being able to use a custom exit_status option.

Why?

When I try to pass a custom :exit_status value to the format_issue opts, it is never applied. Am I missing something?

format_issue(
  issue_meta,
  message: message,
  trigger: mfa,
  exit_status: 0,
  line_no: line_no
)
# exit status is not 0

The tricky thing is that I am defining a Check that could generate:

• 2 types of categories.
• 2 different exit statuses (0 and 16 - warning).

Alternative approaches

How am I bypassing this for now? I am developing a Credo.Check and I do it by modifying the IssueMeta tuple, setting these values, which is a bit "weird", compared with just giving a custom option when formatting it.

As :exit_status is not established when using it (use options), it gets it from the function generated by the macro.

  @doc false
  def exit_status(params, check_mod) do
    params[:__exit_status__] || params[:exit_status] || check_mod.exit_status()
  end

Example:

exit_status = 0 # or the other coming from :warning
issue_meta = case issue_meta do
  {mod, source, params} -> {mod, source, Keyword.put(params, :exit_status, exit_status)
  issue_meta -> issue_meta
end
    
format_issue(issue_meta, ...)

[rrrene]

@rNoz Thx for highlighting and fixing this. I found that :priority was also ignored: b9a76f1

This is remarkable, as this code hasn't been touched in 9 years. It was simply wrong the whole time 😳

[rNoz]

You are welcome, @rrrene. I have another proposal that will facilitate modifying the category directly via the format_issue. This will be really useful when having a Credo.Check that can produce a variety of categories/issues. Can I send a proposal to include it as another option?

[rrrene]

@rNoz I think that could be a good idea, but I would want to ask the question: Are there other attributes that we should be able to set through format_issue/2?

Another question to ask is: Why is a single check belonging to two categories in your case? We had cases in Credo where a single check was producing two kinds of issues and even in that case, we eventually split the check in two to have a clear 1:1 relationship. (this is just me being curious, not trying to patronize you)

[rNoz]

@rrrene This was the main one I missed, but I would understand if it is not supported, precisely because of what you ask below. Nevertheless, as you think is a good idea, I'll create the PR and then you make your final decision :)

It is a special situation, where the same search algorithm is applied for two types of checks that are closely related, but not under the same category and notification level:

• One has a special category for informational purposes, with a recommendation, and will not issue an erroneous exit status (0). So, people can see those without blocking CI pipelines.
• The other is a warning and whenever encountered will issue an error.

But 90% of the search code is the same. Hence time is saved by combining them in the same check.

But it would also be good to leave the two checks independent and each one focus on its search. Let's say we are talking about a trade-off between check performance+algorithm maintainability vs separation of concerns/clarity.