Open msgilligan opened 6 years ago
I agree. Not beeing able to parse a header should be an error and not just a warning. The bake method should indicated if the process was unsuccessful. That way the gradle task could be able to detect the problem and fail which should interrupt the ci pipeline.
The Crawler is the only class which does not collect errors and propagate them to the Oven.
You should be able to circumvent the error if you configure default.status
and default.type
.
Just to recap, if we add config option that causes content parsing warnings to throw an error instead of just being logged as a warning, and the option will be set to false for backwards compatibility. Everyone OK with this?
just to add my 2 cents:
I get a lot of config.adoc has an invalid header, it has been ignored!
warnings, because many of my files are just include files which have no header and thus it is ok that they are not rendered.
I think we should distinguish between "no header" and "invalid header"
I'm using JBake via Gradle and GitLab CI to auto-publish site updates. If something goes wrong with the
bake
Gradle task, I would like the build to fail and the site update not to be published.Instead I get the following warning message and the site publishes with a broken link (404).
Perhaps, for backward-compatibility reasons, there should be a config option to enable fail/abort on error.
Crawler.java
could then have a configuration option to return an error or throw an exception when something goes wrong.