fix: min_coverage parsing with default to 100

[kelvinwieth]

Description

Following the conversation on #287, this PR:

• Solves fix: catch non-numeric min_coverage input  #255
• Makes min_coverage defaults to 100, which is a requirement but the behavior is missing
• Adds a rule for min_coverage to be between 0 and 100.

Type of Change

• ✨ New feature (non-breaking change which adds functionality)
• 🛠️ Bug fix (non-breaking change which fixes an issue)
• ❌ Breaking change (fix or feature that would cause existing functionality to change)
• 🧹 Code refactor
• ✅ Build configuration change
• 📝 Documentation
• 🗑️ Chore

[kelvinwieth]

This may be a breaking change. The current behavior is min_coverage with defaults to 0, and fixing it to 100 would "cause existing functionality to change".

[alestiago]

LGTM! Thank you for working on this! 💙

[kelvinwieth]

@alestiago with the addition of min_coverage between 0 and 100, now I think this is definetly a breaking change. What do you think?

[alestiago]

@alestiago with the addition of min_coverage between 0 and 100, now I think this is definetly a breaking change. What do you think?

I personally don't think this is a breaking change since specifying min_coverage smaller than 0 or greater than 100 was incorrect usage. However, perhaps a less "breaking" solution would be to clamp the values instead of throwing an error, but that might be less intuitive. Either way, I'm fine with both approaches.

[kelvinwieth]

@alestiago can you add the hacktoberfest tag?

[alestiago]

@kelvinwieth I'm not sure how do you want me to do so. Unfortunately this year we didn't prepare to participate in Hacktoberfest (hopefully next year we do!).

[alestiago]

@erickzanardo @renancaraujo @wolfenrain can I get an additional review here?