fix: changes logging for skipped validators to atInfo instead of atSevere in printSummary

[eibakke]

Summary:

We've started using the GTFS validator at Entur in Norway and this message is logged at too high a severity, with no way to disable to logging in the validator itself. If this change is not possible, then it would be great to have a way to opt out of it. Either by defining the validators required when running the validator or by setting a logging config in the validator.

Expected behavior:

Below is a screenshot of what we're seeing currently. We want to change this log message to be at info instead of error severity.

[welcome]

Thanks for opening this pull request! You're awesome. We use semantic commit messages to streamline the release process. Before your pull request can be merged, you should update your pull request title to start with a semantic prefix. Examples of titles with semantic prefixes:

• fix: Bug with ssl network connections + Java module permissions.
• feat: Initial support for multiple @PrimaryKey annotations.
• docs: update RELEASE.md with new process
  To get this PR to the finish line, please do the following:
• Read our Contribution Guidelines
• Follow Google Java style coding standards
• Include tests when adding/changing behavior
• Include screenshots

[CLAassistant]

All committers have signed the CLA.

[davidgamez]

Hoi @eibakke, sorry for the late response. This message is very important as it points out the fact that some notices were not verified due to previous errors like file/column formatting issues. We haven't found a good way to make it to the actual report without confusing non-technical users, as the relationship between validators and notices is unclear. I suggest setting it to warning if this helps to remove excessive logs on your side. Please let me know if this suggestion still is a blocker for your integration.

Suggested change

	logger.atInfo().log(b.toString());
	logger.atWarning().log(b.toString());

[eibakke]

Hi @davidgamez, thank you for following up. Warning sounds like a good middle way. I'll commit the suggestion here.

[eibakke]

Hi David, I discussed with my colleague Vincent Paturet who pointed out that we would also prefer the ability to tune the logging from the validation runner with our logback.xml. Do you use slf4j?

[davidgamez]

Hi @eibakke, we use FluentLogger, which uses java.util.logging under the hood. We do have a logging.properties file in the app module that can be extended to incorporate the ValidationRunner class logging levels. However, this is only for the app module. A similar solution can be implemented, depending how you are integrating the tool in your pipeline.
Reference files:

• https://github.com/MobilityData/gtfs-validator/blob/master/app/gui/src/main/resources/logging.properties

• gtfs-validator/app/gui/src/main/java/org/mobilitydata/gtfsvalidator/app/gui/Main.java

  Line 52 in d9329f0

  try (InputStream inputStream = Main.class.getResourceAsStream("/logging.properties")) {

[davidgamez]

Hi @eibakke, here is a code block that you can use to load a custom logging.properties into your code, link

[davidgamez]

LGTM!

[welcome]

🥳 Congrats on getting your first pull request merged!