Swiftlint: `error` severity for every rule
I couldn't find an answer in the Wiki about failing the build in case of any of the rules are violated. I am not sure this is the right place to ask for clarification, but what I would like to do is to fail the build for the violation of any of the rules which are not disabled. e.g. todo, trailing_comma, valid_docs, etc.. basically almost every rule violation should fail the build.
What would be the way of doing this properly?
Thanks you for your suggestions, I'm not sure if this is the proper place for asking this type of question, but feel free to move my issue.
HunorSzabo
All 6 comments
You can use swiftlint lint --strict. See #834.
marcelofabri
on 25 Jan 2017
Perfect, thanks for your help and the quick reply.
HunorSzabo
on 27 Jan 2017
Feel free to reopen if you have more questions!
marcelofabri
on 27 Jan 2017
--strict is nice, but it would be even nicer to be able to be able to set error as default for every rule via .swiftlint.yml and turn it down to warning for selected other rules.
Use case: For a commit hook which only runs on added/modified files, we like to be strict and have a lot of errors which prevent committing. For the whole code base, reports are generated on CI, it should include more finegrained reports including warnings for rules that should be ignored or have a higher threshold on the commit hook. E.g. warn for method body lines > 40, error for > 100.
fabb
on 23 Jul 2018
@marcelofabri I was looking for the same thing as @fabb suggested. Any plans on adding such a feature? Would be really nice.
rolandleth
on 17 Feb 2020
For inspiration: and eslint supports --max-warnings=0 as a command line parameter.
https://eslint.org/docs/user-guide/command-line-interface
fabb
on 17 Feb 2020
Related issues
zntfdr
路
3Comments
Den-Ree
路
3Comments
BalestraPatrick
路
3Comments
rajohns08
路
3Comments
ivanbruel
路
3Comments
Most helpful comment
--strictis nice, but it would be even nicer to be able to be able to seterroras default for every rule via.swiftlint.ymland turn it down towarningfor selected other rules.Use case: For a commit hook which only runs on added/modified files, we like to be strict and have a lot of errors which prevent committing. For the whole code base, reports are generated on CI, it should include more finegrained reports including warnings for rules that should be ignored or have a higher threshold on the commit hook. E.g. warn for method body lines > 40, error for > 100.