Fix broken compile sketches workflow

[sebromero]

This PR fixes the incorrect configuration of the workflow and the profiles. There were multiple issues:

• Incorrect usage of cli-compile-flags
• Missing local library path
• Unsupported library for Portenta C33 as dependency
• Missing sketch profile files

[github-actions]

Memory usage change @ 292af48

Board	flash	%	RAM for global variables	%
arduino:mbed_opta:opta	❔ -256 - +184	-0.01 - +0.01	0 - 0	0.0 - 0.0
arduino:mbed_portenta:envie_m7	N/A	N/A	N/A	N/A
arduino:renesas_portenta:portenta_c33	N/A	N/A	N/A	N/A

Click for full report table

Board	extras/tests/TestExisting flash	%	extras/tests/TestExisting RAM for global variables	%	extras/tests/TestFileOperations flash	%	extras/tests/TestFileOperations RAM for global variables	%	extras/tests/TestFolderOperations flash	%	extras/tests/TestFolderOperations RAM for global variables	%	extras/tests/TestRepeatedFormatMount flash	%	extras/tests/TestRepeatedFormatMount RAM for global variables	%	examples/AdvancedUSBInternalOperations flash	%	examples/AdvancedUSBInternalOperations RAM for global variables	%	examples/BackupInternalPartitions flash	%	examples/BackupInternalPartitions RAM for global variables	%	examples/Callbacks flash	%	examples/Callbacks RAM for global variables	%	examples/InternalStoragePartitioning flash	%	examples/InternalStoragePartitioning RAM for global variables	%	examples/Logger flash	%	examples/Logger RAM for global variables	%	examples/SimpleStorageWriteRead flash	%	examples/SimpleStorageWriteRead RAM for global variables	%
arduino:mbed_opta:opta	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	-72	-0.0	0	0.0	-72	-0.0	0	0.0	-256	-0.01	0	0.0	N/A	N/A	N/A	N/A	-72	-0.0	0	0.0	184	0.01	0	0.0
arduino:mbed_portenta:envie_m7	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A
arduino:renesas_portenta:portenta_c33	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A	N/A

Click for full report CSV

Board,extras/tests/TestExisting<br>flash,%,extras/tests/TestExisting<br>RAM for global variables,%,extras/tests/TestFileOperations<br>flash,%,extras/tests/TestFileOperations<br>RAM for global variables,%,extras/tests/TestFolderOperations<br>flash,%,extras/tests/TestFolderOperations<br>RAM for global variables,%,extras/tests/TestRepeatedFormatMount<br>flash,%,extras/tests/TestRepeatedFormatMount<br>RAM for global variables,%,examples/AdvancedUSBInternalOperations<br>flash,%,examples/AdvancedUSBInternalOperations<br>RAM for global variables,%,examples/BackupInternalPartitions<br>flash,%,examples/BackupInternalPartitions<br>RAM for global variables,%,examples/Callbacks<br>flash,%,examples/Callbacks<br>RAM for global variables,%,examples/InternalStoragePartitioning<br>flash,%,examples/InternalStoragePartitioning<br>RAM for global variables,%,examples/Logger<br>flash,%,examples/Logger<br>RAM for global variables,%,examples/SimpleStorageWriteRead<br>flash,%,examples/SimpleStorageWriteRead<br>RAM for global variables,%
arduino:mbed_opta:opta,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,-72,-0.0,0,0.0,-72,-0.0,0,0.0,-256,-0.01,0,0.0,N/A,N/A,N/A,N/A,-72,-0.0,0,0.0,184,0.01,0,0.0
arduino:mbed_portenta:envie_m7,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A
arduino:renesas_portenta:portenta_c33,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A,N/A

[sebromero]

@per1234 Any idea why the linter cannot parse the sketch.yml files? Looks like it doesn't like the - dir: ../../ entry in libraries. It's been added to the CLI not too long ago. Is it just not supported yet in the linter?

[per1234]

At the time Arduino Lint was written, the code in Arduino CLI was intended to be able to be used by other Go applications. For this reason, the approach taken in writing Arduino Lint was to attempt to leverage as much of the existing capabilities of Arduino CLI.

Years later, Arduino CLI team made the decision that it would not be feasible to maintain a public Go API for all the internal capabilities of Arduino CLI. Almost the entire API was made internal; only for use within the Arduino CLI application itself. This made it impossible to update Arduino Lint's github.com/arduino/arduino-cli Go module dependency past the point when that change was made. So Arduiono Lint is stuck using the outdated version arduino/arduino-cli@1f8d0f6c0dd3.

At that time, the libraries sequence of the build profile only supported library name strings, so when this version of Arduino CLI attempts to process a sketch that contains a build profile with a dir mapping in the sequence instead of the expected string type, it panics.

The way forward for Arduino Lint is to remove all dependence on Arduino CLI. There is significant use of the Arduino CLI dependency in the Arduino Lint codebase, so doing that will not be trivial. Previously, although it was unfortunate to have an outdated dependency, the situation didn't impact Arduino Lint's functionality as the capabilities of the outdated Arduino CLI version were perfectly sufficient for Arduino Lint's needs. So hasn't been a compelling motivation to dedicate limited resources towards that work.

---

Do you really feel that it is necessary to add sketch project files to the library? The feature is very valuable for development of standalone projects, but I am not at all convinced it makes sense to use it for library examples.

Build profiles are not supported by Arduino IDE or Arduino Cloud Editor, so the majority of users won't be using the profiles. Example sketches are typically only actually used a few times as a quick "hello world", so even for the small subset of users working directly with Arduino CLI, the presence of a build profile is only a minor convenience at most.

I'm not convinced it makes sense to add the files for the sake of the CI system, since this means the CI system is validating the sketches in a different context than the one that will be used by most users.

So it seems to me that the presence of sketch project files would mostly only be useful to the library developers who are compiling the examples frequently, and only if those developers are using Arduino CLI directly. So the question of whether all these files should be added to the library really comes down to whether the library developers find the build profiles to be significantly useful.