arduino / arduino-cli

* Added 'examples' field in rpc.Library

* Added lib examples command

* Fixed case in json output

* Fixed coloring

* Allow library listing filter by name

* Added function to compute library location priority

* Sort examples results by name

* Added fqbn filtering for libraries

* Sort lib list output by name

…tion (#930)

The term "Boards Manager" has been well established in the Arduino development tools and documentation. Perhaps influenced by the mismatch with the singular term used for its companion "Library Manager", Arduino CLI's documentation has diverged from this standard by sometimes (but not always) referring to it as "Board Manager". This PR resolves the inconsistency by using "Boards Manager" everywhere.

Note that "Boards Manager" and "Library Manager" are proper nouns, and so should always be capitalized.

…#925)

* Document the programmers.txt configuration file of the Arduino platform system

This file is used to define external programmer configurations to be used for burning bootloaders and programming Arduino boards.

NOTE: the example programmer snippet is missing some of the properties that are defined in the real programmer definition in the Arduino AVR Boards platform. After a lot of investigation, experimentation, and even consulting with the original author of the code, I was still unable to find any use of these properties in the current or any past IDE version that supported the 1.5 platform format. If these properties have no purpose, they they only represent a source of confusion and maintenance burden for platform developers.

* Document the "Upload Using Programmer" configuration system of Arduino platforms

* Document the "Burn Bootloader" configuration system for Arduino platforms

* Document programmer inheritance from referenced core platforms

Previously, all programmers of all platforms of the same architecture could be used. The behavior of the Arduino IDE was changed in the 1.8.13 release in this matter, and Arduino CLI and Arduino Pro IDE followed the same behavior from the initial introduction of support for programmers. This means it's now important to document programmer inheritance.

* Add external programmers listing to board details commmand

* Remove hack to return list of programmers calling upload command

* Add gRPC interface to collect every sketch file

* Rename SketchLoad to LoadSketch and fix some gRPC messages

* update to codeclysm/extract/v3

* Updated extract to 3.0.1. Run of go mod-tidy

Co-authored-by: Cristian Maglie <[email protected]>

* Fix NPE for 'board install' command

The NPI is triggered if Platform.Resource is nil (this may happen for
platforms installed manually in the sketchbook/hardware directory for
example).

Related to #759

* Update translations

In order to specify multiple Boards Manager URLs via a single --additional-urls option, they must be in a comma-separated list.

* Added executils.Process helper

This helper should avoid common pitfalls arising mainly after the adoption
of the 'avrdude-stdin-hack'. For example see #904
It also streamlines some of the most common operations (like process
Kill or Signal).

* Removed no more used executils.Command

* Run 'board list' test anyway

Even if no board are attached to the host system, it's always another
smoke-test that runs automatically.

Having this check enabled, for example, would have prevented:
#904

…l not compile beforehand. (#919)

* Changed core install message

* Removed useless condition (letfover)

* Convert errors running post_install into warnings

… resilient) (#913)

* Refactored executils.Command

* Added IsTrusted flag in PlatformReleases

This is required for post_install script processing.

* Run post_install.sh script on trusted platforms

* Small fix on post-install precondition

* Use absolute path for running post_install script

* Added --skip-post-install flags. Refactored PostInstall function.

* Run post-install scripts by default only if the CLI is interactive

This should prevent CI-based runs to block waiting for user interaction.

* Added post_install run messages

* fix wrong assert in other test

* add automatic `core update-index` when `package_insex.json` are not there

* Fix typos in documentation

* Improve formatting of documentation

* Use correct case for Arduino CLI name in documentation

Co-authored-by: Roberto Sora <[email protected]>

Co-authored-by: Roberto Sora <[email protected]>

… documentation (#906)

* Restructure paragraph re: standardizing architecture names

The information about architecture values being case sensitive was placed in the middle of a largely unrelated paragraph.

The paragraph about using standardized architecture names had an overly strident tone, which I have softened.

* Improve wording of documentation

Do some minor rewording of sentences to improve clarity and readability, but without changing their informational content.

When I build the CLI on Windows, I do not want to see the executable as
an outgoing Git change. Same as on POSIX.

Signed-off-by: Akos Kitta <[email protected]>

… avrdude running in safe mode) (#897)

Some tools detects if the program is running from terminal by looking at the stdin/out bindings.
Previously stdin wasn't bound to any custom stream, this fact lead avrdude to think it was run from terminal (instead of a script) and start it in "safe-mode". This turn out to be a problem in some cases, see #844

* Removed useless stdout/err listeners

They are immediatly overwritten on the next line.

* Always pipe stdout/err/in when running tools.

This is required because some tools detects if the program is running
from terminal by looking at the stdin/out bindings.

Fix: #844

* Do not use NullWriter in executils by default.

This is not strictly required for the 'avrdude' hack.

…definitions (#901)

Prettier is configured to wrap lines in Markdown files at 120 characters. The reference definitions for the nightly ARM downloads happen to be longer than 120 characters, and so get wrapped.

With the modern Markdown specification, this is permitted:
https://spec.commonmark.org/0.29/#link-reference-definitions

> A link reference definition consists of a link label, indented up to three spaces, followed by a colon (:), optional whitespace (including up to one line ending), a link destination

but apparently the Python-Markdown renderer used by MkDocs does not support this.

The solution is to remove the line breaks and markup to instruct Prettier to ignore these lines:

https://prettier.io/docs/en/ignore.html#markdown

* add fqbn flag for `board details` command

* update cobra to get new zsh completion spf13/cobra@2c5a0d3 and to fix this spf13/cobra@675ae5f

* add --no-descriptions also for zsh

* update docs

* update tests

* removed hack spf13/cobra#1121

… workflow (#877)

* [skip changelog] Build is now uploaded as artifact when running tests workflow

* [skip changelog] Added more information to workflow artifacts

* [skip changelog] Fix artifacts paths

* [skip changelog] Update upload-artifact action version in test workflow

* [skip changelog] Test artifacts are now uploaded separately

…rom running in forks (#888)

* Disable workflows that would always fail from running in forks

These workflows use resources that are only available when run in the arduino/arduino-cli repository, so would always fail when they run in a repository. They are of no value to fork repositories. They are triggered by the schedule event, so they cause regular annoying and confusing workflow failure notifications for every fork owner.

* Don't trigger link validation CI workflow on schedule event when in a fork

The docs workflow was split into two workflows: publish-docs and validate-docs, but the references to the original workflow were not updated.

…pushes to any branch (#887)

* Split docs workflow into validate and publish workflows

The docs workflow had two uses:

- Check that changes to docs don't break the static website build system
- Publish the docs to the website

To make the CI system friendly to contributors, it should be easy for them to validate documentation changes from a feature branch, meaning the validation aspect should run on a push to any branch. However, the special behavior of the workflow to publish on pushes conflicted with that usage. The most simple solution is to split the workflow into two. The validation workflow contains the process of interest to contributors, and is thus made friendly to their development process. The publishing workflow is not of interest to contributors, and thus doesn't need to be configured to run on pushes to any branch.

* Run workflows that are useful to contributors on push to any branch

Contributors should run CI in their feature branch to make sure it's passing before submitting a PR. Previously, the CI workflows were configured to run only on push to the master branch, meaning that contributors would need to modify the workflows just to get them to run on a feature branch. It's very unlikely that a contributor would do that, so they are more likely to just submit the PR, then if CI on the PR fails push fixup commits until CI is passing.

The solution is simply to remove the filters that caused the workflows to run only on push to master.

The v1.1.0 version of the action neglected to define its repo-token input in the metadata, which results in a `Unexpected input(s) 'repo-token', valid inputs are ['version']` warning shown in the workflow summary on every run. The v1.1.1 release remedies this.

The use of the v1 ref will allow the workflows to benefit from any new releases of the action that don't cause breaking changes.

…teps of test workflow (#886)

* Use v1 ref of codecov/codecov-action GitHub Actions action

Previously, the workflow pinned the outdated v1.0.2 ref. The requirement for an upload token has been removed since the 1.0.2 release. Removing the token input will provide several benefits:

- Prevent failures when the workflow is run in forks, which won't have the CODECOV_TOKEN secret defined.
- Allow configuring the workflow to be triggered by pull_request events, making it easy to evaluate the impact the pull request has on code coverage.

The use of the v1 ref, rather than pinning a specific version allows the workflow to automatically benefit from ongoing development work on the action, while still preventing it from being affected by breaking changes.

* Remove unnecessary token input from Codecov upload steps of test workflow

With the modern versions of the codecov/codecov-action GitHub Actions action, the upload token is only required for private repositories. Now that we are using a modern version of the action, this input only has a harmful effect by causing the workflow to fail when run in forks and also preventing us from using Codecov to evaluate the impact on code coverage of pull requests.

* Add FAQ item re: Serial Monitor

* Mention gRPC Monitor service in Serial Monitor FAQ