GitLab

The inherited resources resulting from a core reference are clearly documented. However, the variant reference mentioned the non-inheritance of platform.txt properties alone. For me, this left it unclear whether the lack of mention of the other resources implied that variant and tool references resulted in their inheritance, and that it was only considered necessary to document it once in the platform reference documentation.

One option for resolving this would be to remove the statement that caused the confusion. However, since this is a complex subject, I thought it better to just explicitly document the non-inheritance of the resources in both the variant and tools reference sections of the documentation to make it completely clear.

* Remove deprecation from importFile param

* Implement --input-file flag

* Add comment in --input-file splitting step

* Add e2e test for --input-x flags

* Refine upload flags testing

* Add --input-file file existence check

* Use TrimSuffix instead of replace

* Restore -i shorthand flag for --input-file and add CLI checkFlagsConflicts function

* Improved build path and project name auto-detection

This should make the upload command compatibile with all the reasonable
usages.

See #764
See #641

* Made UploadTest more resilient

* upload: sketch is ignored if input-dir or input-file is specified

There is no point in overriding the sketch name if the user explicitly
give it via command line.

* Update go-paths-helper to version 1.3.2

fixes EquivalentTo when used with abs paths

* fix TestGetCommandLine

* 100% coverage on detectSketchNameFromBuildPath function

* Do not git-ignore all *.bin but just inside the client_example folder

* slightly simplified function signature (cosmetic)
Co-authored-by: Cristian Maglie <c.maglie@arduino.cc>

The arduino/arduino-cli repository's automatic changelog generation system adds a changelog item for every commit, except those that start with "[skip changelog]". This is useful for keeping the changelog to only mentioning the changes that are significant to the user.

All pull requests are merged using GitHub's "Squash & Merge" feature.

The behavior of "Squash & Merge":

- If the PR only contains a single commit, the pre-filled squash commit message is taken from the commit, not the PR.
- If the PR contains multiple commits, the prefilled squash commit title is the PR title.

This means that a PR will end up in the changelog against the wishes of the contributor when all of the following occur:

- The PR author followed the instructions and only added "[skip changelog]" to the PR title.
- The PR only contains a single commit.
- The maintainer who merges the PR uses the pre-filled commit message provided by GitHub.

The first two conditions are common. There is evidence that the third will also be common.

To make the instructions as easy as possible to follow, the contributor is now instructed to add "[skip changelog]" to both the commit message and PR title, even though it is really only necessary to add it to one or the other, depending on the conditions.

* [skip changelog] Remove monitor test in daemon mode

* Missing mod tidy

* Refactored commaSeparatedToList function

* Added 'provides_includes' field in 'lib list' output structures

* Added integration tests for 'provides_includes' field

* Report errors while populating library output

* 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

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.

* 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 <c.maglie@arduino.cc>

* 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 https://github.com/arduino/arduino-cli/pull/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:
https://github.com/arduino/arduino-cli/pull/904

[skip changelog] Clarify in documentation that the upload command will not compile beforehand. (#919)

* Changed core install message

* Removed useless condition (letfover)

* Convert errors running post_install into warnings

* 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 <r.sora@arduino.cc>
Co-authored-by: Roberto Sora <r.sora@arduino.cc>

* 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 <kittaakos@typefox.io>

Always redirect stdin to null (fix tools tty detection, in particular 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: https://github.com/arduino/arduino-cli/issues/844

* Do not use NullWriter in executils by default.

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

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 https://github.com/spf13/cobra/commit/2c5a0d300f8ba1cd142776508519aba999b5e77f and to fix this https://github.com/spf13/cobra/commit/675ae5f5a98cc705a6d54f4c487ab81230604137

* add --no-descriptions also for zsh

* update docs

* update tests

* removed hack https://github.com/spf13/cobra/issues/1121

* [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

* 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.

* 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.

* 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