I'm using spring-restdocs to generate docs.
I'm wondering if any property to fail the asciidoctor task while getting similar warnings when building the doc.
Snippet http-response not found at ../../../build/generated-snippets/find-list-configuration-fixed-assets-source-response/http-response.adoc for operation find-list-configuration-fixed-assets-source-response
Snippet path-parameters not found at ../../../build/generated-snippets/update-currency/path-parameters.adoc for operation update-currency
Unfortunately, this is not possible. There is an open issue https://github.com/asciidoctor/asciidoctor-gradle-plugin/issues/154 since 2015. If you read through this issue you will find a workaround. Maybe it will help you. :-)
This is possible starting with asciidoctor 2.0, by configuring the fatalWarnings option of asciidoctorj.
Documentation of fatalWarnings:
Patterns for AsciidoctorJ log messages that should be treated as fatal errors. The list is empty be default. Use setFatalWarnings to clear any existing patterns or to decouple a task’s configuration from the global configuration. Use fatalWarnings to add more patterns. Pass missingIncludes() to add the common use-case of missing include files.
Example:
asciidoctor {
asciidoctorj {
fatalWarnings missingIncludes()
}
}
Related
I was looking for a configuration parser for go and https://github.com/spf13/viper seems to come highly recommended.
I am very surprised to find that configuration files are not validated by default.
Viper parses files and extracts requested values from them but I cannot find a way to detect bad configuration.
For instance I if create a (Java style) .properties file containing just "???" and nothing else. This is accepted without any error.
I can understand the philosophy that you should ignore irrelevant configuration items but I desire more rigor. I would also like to reject anything that does not match the X=Y format in a properties file.
To me this is a fatal flaw that suggests I should use a different package (or roll my own as usual).
Have I missed something? Does viper in fact support detecting and rejecting bad configuration keys?
I think the answer is no. viper does not validate java .properties files.
I posted a bug report (or feature request depending on your point of view) as https://github.com/spf13/viper/issues/790
You can try https://github.com/num30/config library which is based on Viper. It has built-in validation.
I've got a Java/Maven project that uses RestDocs to generate documentation of our endpoints.
For the uninitiated of RestDocs, what it does is monitor tests during the build and use information from the tests to generate "snippets" that get used to create API documenation using asciidoc during the mvn package phase.
The problem I'm facing is that if the asciidoc (.adoc) file is referencing a non-existent snippet, the doc gets generated and will say something like:
"Unresolved directive in myDoc.adoc - include::{snippets}/error-example/response-fields.adoc[]"
Since this happens after the tests, I don't know how to test for something like this so that the build can stop and let the developer know that they need to update either the .adoc or the snippet.
Any guidance would be much appreciated.
Adding this to the configuration of the asciidoctor plugin fails the build when a snippet is not found that the .adoc is expecting:
<logHandler>
<outputToConsole>true</outputToConsole>
<failIf>
<containsText>include file not found</containsText>
</failIf>
</logHandler>
I have a web app project where the quality is measured under sonarqube.
As i'm dealing with an external code within my project files
Recently i have had some issues appearing due to that exetrnal code and which i'm not focusing on its quality :
So i wanna just delete the issue to appear from my sonar dashboard (which looks like the following):
The solutions that i have had where not really usefull , as :
i was suggested to change the level of the rule itself from "issue" to "info" :
And of course that seems to be not usefful because , i won't affect the rule itself
the second suggestion was to use the :
#SuppressWarnings decorator in my blocks of code where the issues appeared ; : for example use it under classes or methods or even fields
-> this method results in adding some code to my extarnal code and that won't be also good as i'm not even having the permission to do it.
I wanna just the simpliest solution to delete the issue from the sonar dashboard , just suppress it from the SonarQube interface , strangely it seems that there is no a direct way to do it :
Any better ideas ??
The easiest way is excluding external code from the report with narrowing the focus feature.
Just add to your sonar-project.properties file path pattern to exclusion, for example
# Exclude all classes ending by "Bean"
# Matches org/sonar.api/MyBean.java, org/sonar/util/MyOtherBean.java, org/sonar/util/MyDTO.java, etc.
sonar.exclusions=**/*Bean.java,**/*DTO.java
# Exclude all classes in the "src/main/java/org/sonar" directory
# Matches src/main/java/org/sonar/MyClass.java, src/main/java/org/sonar/MyOtherClass.java
# But does not match src/main/java/org/sonar/util/MyClassUtil.java
sonar.exclusions=src/main/java/org/sonar/*
If you're not interested some issues because it's not your code, then you should not have SonarQube analyze that code. According to the SonarQube documention:
We recommend that you exclude generated code, source code from
libraries, etc.
You should check in particular the following settings in the same documentation page:
sonar.sources
sonar.exclusions
These settings will be taken into account the next time you run an analysis.
I am using guard-jasmine create coverage reports for my javascript app written with backbone js. I would like to exclude the template files from being included in the coverage. Is there a way to do this currently? I have also tried looking through the source and passing the -x option to the intrument command in the coverage.rb file but that doesn't seem to help at all. Any pointers would be appreciated.
Thanks!
There is currently no way of configuring Guard::Jasmine to skip specific files from generating the coverage.
A possible way to add this would be to add something like a coverage_skip option that contains a regex to check it as a preconodition in the coverage tilt template:
return data if file =~ ENV['COVERAGE_SKIP']
Since we do not have access to the Guard::Jasmine options, we need to set it as an environment variable in the server process.
A pull request is heartly welcome ;)
Does anyone has an example how to use the sourceFileExcludes element in the Maven Javadoc Plugin? I've tried the following, but cannot get it to work:
<sourceFileExcludes>
<sourceFileExclude>**/internal/*</sourceFileExclude>
<sourceFileExclude>**/Model/*</sourceFileExclude>
</sourceFileExcludes>
Have you specified excludePackageNames, cause based on the docs you should use them instead of what you've written.
<excludePackageNames>*.internal:org.acme.exclude1.*:org.acme.exclude2</excludePackageNames>
which seemed to be more approriate.
It might just not be working at the moment. There is bug logged in the plugin issue tracker - MJAVADOC-365