Add support for platform properties introduced for pluggable discovery #267
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
per1234
added
type: enhancement
Copy/paste errors.
An optional property may have a required subproperty. Previously, the test only allowed testing for required root properties, by removing the property entirely. In order to test for required subproperties, it is necessary to add a root property that is missing the subproperty in addition to removing the required property.
Used as a convention for years, the integer terminal subproperty's use as an array syntax has now been formalized as a
"list" type. Although the properties package provides a function to parse this data type, it still takes some code
acrobatics to convert that into the map[string]interface{} type consumed by the JSON schema parser, which is a candidate
for a function.
Another "set" data type has also been added, but I don't have an immediate need for it, so will wait to add
support.
The new pluggable discovery system for Arduino boards platforms introduces a new set of `pluggable_discovery.*` properties to the platform.txt configuration file, which have requirements to be enforced via Arduino Lint rules.
…nction Due to the complexity introduced to the data format via the custom board options system, I was not able to find any way to define some of the boards.txt rules via the JSON schema. These were implemented in pure Go code. The requirement has emerged to check whether a required property exists either as a terminal property or as a parent property (e.g., `uno.upload.tool` or `uno.upload.tool.serial`). A helper function is already present with the logic for handling the check of whether the property exists either directly based on the board ID or as a custom board option property, but it didn't have the parent property support, which is added here.
This boards.txt property is the replacement for `upload.tool`. `upload.tool` will still be supported, and there are no additional requirements on the new property style. So it is only necessary to make the schema and rules apply to either.
This is an enum that contains the supported string representations of Boolean values. It was previously used only by the boards.txt schema, and so was hosted in its file, but now there is a need for it in the platform.txt specification as well, so it goes in the file that holds the shared definitions.
The Arduino project configuration files make an unusual usage of the "properties" data format in that sometimes a `.` in a key name indicates a nested data level, while other times it is only a character. There are cases where a completely programmatic recursion of the properties into a fully nested structure would result in the impossibility of some keys having both a string and a map type, which is not supported by the Go map type that holds the recursed data, nor the JSON data format it is validated against. For this reason, it's necessary to manually configure the recursion of key levels on a case-by-case basis and the approach is taken of recursing only when necessary. Previously, it was possible to treat the params.verbose/quiet component of the `tools.TOOL_NAME.ACTION_NAME.params.verbose/quiet` properties as being just key names. However, the addition of the `tools.TOOL_NAME.upload.field.FIELD_NAME` and `tools.TOOL_NAME.upload.field.FIELD_NAME.secret` properties requires one more level of recursion in order to deal with the fact that the FIELD_NAME component is arbitrary. This resulted in splitting the params.verbose/quiet property, which required adjustments to their schema and rules.
Some upload recipes might require custom fields that must be provided by the user. The platform author can define such fields via two new property types that have been added to the Arduino platform system with the expanded pluggable discovery support. There are some requirements for these fields, which are enforced via a couple of new rules.
Pluggable discovery brings support for variants of the upload properties for each protocol. In addition to the previous property names, the same rules must now be applied to the properties with an arbitrary protocol name inserted.
silvanocerza
approved these changes
Sep 2, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Full support for pluggable discoveries has been added to Arduino CLI (arduino/arduino-cli#1333). Support for the package index project aspects was added in #204. New platform properties with specific requirements imposed by the build system were also added. Support and enforcement of these by Arduino Lint is added here.