Linting

We allow customers to configure their own linter settings and configuration. However, the pipeline stage must pass for Certificate to Field (CtF) and to deploy to staging. The pipeline will automatically lint code according to the chosen linter and lint configuration file. If the pipeline is not working for the chosen linter or the chosen linter is not implemented, please open a help desk ticket .

Recommended Linters

Language	Recommended Linter	Configuration File	Notes
Python	pylint	.pylintrc	Use ignore-patterns instead of ignore for excluding files or directories from pylint
JavaScript	eslint	.eslintrc
Java (Gradle)	checkstyle	checkstyle.xml	Please add the following to your build.gradle file in order to utilize checkstyle for linting: Additionally, create a checkstyle.xml file within the folder config/checkstyle in the root of your project. Here is an example checkstyle.xml file. For more information: CheckStyle Gradle plugin.
Java (Maven)	checkstyle	maven_checks.xml	Below is sample xml that can be added to your pom.xml file to enable the checkstyle plugin: See additional notes below concerning the configuration options for checkstyle.
C++	cpplint	CPPLINT.cfg
Ruby	ruby-lint	ruby-lint.yaml
Golang	golint	n/a	Golang standards are set by the language itself.
Dotnet	dotnet format	.editorconfig	Dotnet format

Additional Notes Concerning the Java (Maven) Checkstyle Plugin

1. The configLocation parameter is the path to the file that defines the lint rules that will be used. In the example above, it is looking for a file named maven_checks.xml located at the project root. If the file is located elsewhere in the project, the path to the file needs to be included.
2. For projects that have their source files in a directory other than the src directory, there is an optional parameter named sourceDirectory that will need to be set to the directory with the source files.
3. The violationSeverity parameter and the failOnViolation parameter together set the minimum violation level that must be found before the stage fails. Different checkstyle lint rules set their violation severity differently, some using "error" as their maximum and others using "warning" as their maximum. We suggest setting violationSeverity to match the maximum violation severity available in the ruleset that is chosen.
4. There is also an optional parameter named suppressionsLocation, which would contain a link to the file containing the lint suppressions filter.
5. There is also the option to bind checkstyle to run as a part of the standard Maven lifecycle phases. Doing this is discouraged as this may cause unintended behavior, such as checkstyle accidentally running during the unit test phase or the package phase compiling the code a second time during the lint phase.