In order to catch platform-specific bugs, the "Test Go" workflow uses a job matrix to run the tests on multiple runners.The step that uploads code coverage data to Codecov is intended to run only during the Linux job. The runner name`ubuntu-latest` was used in the conditional to accomplish this. However, it might become necessary or desirable to pin aspecific runner version (e.g., `ubuntu-18.04`). The accompanying adjustment to the conditional might be forgotten andthere would not be any obvious sign that the coverage upload had stopped, nor why.This will be avoided by using the general `runner.os` context item to identify the Linux job in the conditional. Thiswill not be ideal in the event multiple Linux runners are added to the workflow's job matrix, but this is less likely tooccur and a redundant coverage data upload shouldn't cause any problems.

This projects contains two Go modules, one in the root and one in the `docsgen` subfolder. More will be added. In orderto support checks on the supplemental modules in the project subfolders, it's necessary to configure the commands to runfrom their path. This is passed to the task via the GO_MODULE_PATH environment variable. If this variable is not defined,the default root module path is used as default, preserving the previous task behavior.The workflows use a job matrix to allow easy configuration for any number of module paths and a dedicated parallel jobfor each module.

Many of the rule messages contain a URL that can be visited to find the detailed information about the problem and howto fix it.Moving this information to a dedicated field in the struct allows for improved formatting of the rule output as well asenhanced capabilities for the use of this data in other applications.

Some of the content has been moved to a new URL. Although the visitor was redirected to the new location, meaning theywere not exactly broken, it is better to send them to the right location from the start.

These will make it easy for users to find information about the problem that caused the rule violation, and how to solveit.

The `Description` field of the rule configuration was previously only used to add supplemental information to the verbosetool output. In this usage, it did not need to stand on its own as a complete documentation of the rule, and also was nota high priority since the verbose output is likely not as frequently used.A new requirement for the rule configuration data has emerged from the project to publish a list of rules. The`MessageTemplate` data is not suitable for use in this application due to being written for use in indicating a problemthat was found, rather than a documentation of the rule. The new requirement is compatible with the existing use of the`Description` field, so it is not necessary to add a new field. However, the existing content of the `Description fieldis mostly not inadequate, so it must be expanded.This content is now written in Markdown. Its existing use is limited to the JSON format output. Since the Markdown syntaxis very lightweight and intuitive, and any reader of the JSON format output will already have been presented with plentyof syntax, I don't think the change has a harmful effect on that output.

The tool output and rules list assume that the text in the required rule configuration fields is present. In cases whereit is left empty, this assumption might result in strange or misformatted output. At the moment they are all populated,so that assumption is fine. In the event the test catches an empty field, it can either be fixed or the code changed tonot rely on that field being populated.

This will provide a convenient reference for information about the rules Arduino Lint applies to projects.- More verbose description of the rule than would be appropriate for the command line output.- Link to the reference information that will allow the reader to fully understand the cause of the rule violation and  how to fix it.- Table showing the rule violation level (i.e., error/warning/disabled) vs. common tool configuration.I added a bespoke "Rules > Introduction" page to give some general information about the rule system. , but the "Sketch","Library", "Platform", and "Package index" pages are all auto-generated from the Arduino Lint source code and will beautomatically updated any time rules are added or modified without any additional effort.The rule documentation content is generated by the "ruledocsgen" Go program, which is a separate module, located in itsown subfolder of the repository, similar to the standardized "docsgen" program that generates the command line reference.

…iptionsSome of the rules must refer to data paths in configuration files such as the package index. In the case of arrays, it isnecessary to indicate that the reference applies to an arbitrary element. Prefiously, the `[]` syntax was used for thispurpose (e.g., `packages[].tools[]`). It is now changed to using `[*]` (e.g., `packages[*].tools[*]`).

The primary purpose of text of the rule configuration's `Description` field is for display in the rule reference sectionof the documentation website. For this reason, it is written in Markdown, and thus can be output as is.The situation is different with the rule configuration's `Brief` field, since it is displayed prominently in the tooloutput. For this reason, the use of Markdown would not be appropriate. This text may contain incidental markup charactersthat would result in unwanted formatting and thus the `Brief` field text must be escaped for display on the website.

…nnerThere is a convention of configuring Arduino boards platforms to provide a user interface for configuring the buildprocess through the addition of references and fallback empty definitions of a series of properties that follow theformat of `compiler.<pattern type>.extra_flags`, where "<pattern type>" corresponds to the compilation pattern thatreferences them:- `c`- `cpp`- `S`- `ar`- `c.elf`Previously, `x` was used as a placeholder for the component of the property name that varies in order to allow a singlerule to refer to the entire set. "<pattern type>" is a little bit more clear than "x".

…rule messagesFeedback was provided that the previous "additional" term was not very clear. "Unrecognized" was determined to be better.

ubidefeo left a comment