- 02 Sep, 2021 1 commit
-
-
Silvano Cerza authored
* Fix upload command not working as expected when certain flags are used * Fix absurd upload corner case
-
- 01 Sep, 2021 2 commits
-
-
Silvano Cerza authored
* Fix integration tests detected_boards fixture * Fix builtin discoveries not loaded if no platform is installed * [skip changelog] Add missing breaking change to UPGRADING.md * [skip changelog] Fix board list test running on CI * [skip changelog] Fix UPGRADING.md
-
Silvano Cerza authored
* [skip changelog] Skip boards without FQBN in tests * [skip changelog] Fix esp32 integration test on darwin
-
- 31 Aug, 2021 4 commits
-
-
Silvano Cerza authored
-
Silvano Cerza authored
-
Silvano Cerza authored
-
Silvano Cerza authored
* Add ways to let users verify if new CLI released * Code review fixes Co-authored-by:
per1234 <accounts@perglass.com> * Enhance docs Co-authored-by:
Cristian Maglie <c.maglie@arduino.cc> Co-authored-by:
-
- 30 Aug, 2021 2 commits
-
-
Silvano Cerza authored
-
Cristian Maglie authored
* Proper gRPC error handling * Update gRPC API of board command to return status.Status instead of error * Update gRPC API of remaining commands to return status.Status instead of error * Replace custom error with protobuf message Previously, a custom error was returned when attempting to upgrade a platform that was already at the latest available version. There is dedicated code for handling this specific error. Now that the function has been changed to return a status.Status instead of error, the previous check for the return being this error is no longer possible. The capability is restored by replacing the error with a protocol buffer message. * Handle details of any type in `core.PlatformUpgrade()` status The status details of the function are used to identify the specific cause of a non-nil status. This is done via a type assertion. Previously, this type assertion was configured such that a details of any type other than the expected would result in a panic. At the moment, that will not occur because we only add details of one type. However, the whole point of the type assertion is to support details of multiple types, and if other types are added a panic will not be the appropriate behavior. A better approach is to check the result of the type assertion, handling the non-nil status as a generic error if its details are of a different type. * Return nil on program action if an error occurred * Refactoring 'upload' commands * Refactoring 'board' commands * Refactoring 'compile' commands * Refactoring 'core' commands * Refactoring 'debug' commands * Refactoring 'lib' commands * Refactoring 'sketch' commands * Refactoring 'commands' commands * updated tests and fixed some error wording * fixed go lint warnings * Apply suggestions from code review Co-authored-by:
Silvano Cerza <3314350+silvanocerza@users.noreply.github.com> * fix i18n Co-authored-by:
-
- 27 Aug, 2021 1 commit
-
-
Roberto Sora authored
[skip changelog] Refactor and add `TEST_LDFLAGS` to `test-unit-race` and `test-legacy` tasks (#1417) * Bump version of golang in go.mod to 1.16 to align with ditribution containers * Refactor and add TEST_LDFLAGS to test-unit-race and test-legacy tasks in Taskfile * Run
-
- 26 Aug, 2021 3 commits
-
-
Cristian Maglie authored
* Simplified utils.Match function * match func doesn't need err anymore * Removed leftover * Removed unused mutex * Factored out all duplicated match helpers * fix i18n
-
Giampaolo Mancini authored
* Add completion for PowerShell * Manage command description for PS completion * Add test for PS completion * Add PS documentation * Fix formatting * Fix python lint for PS tests * Update docs/command-line-completion.md Co-authored-by:
-
Silvano Cerza authored
-
- 25 Aug, 2021 2 commits
-
-
Silvano Cerza authored
-
Silvano Cerza authored
-
- 24 Aug, 2021 5 commits
-
-
Cristian Maglie authored
-
Silvano Cerza authored
-
irieda authored
-
Silvano Cerza authored
-
Silvano Cerza authored
-
- 23 Aug, 2021 1 commit
-
-
Silvano Cerza authored
* [skip changelog] Add DiscoveryManager to PackageManager * Add loading of PluggableDiscoveries when loading a platform release * Added compatibility layer for non-pluggable platforms * Implemented board list with discoveries * Implemented discovery loading after initialization * Implemented board watch with discoveries * Fix load discoveries tests * Fix some issues with board list watcher * Fix FindToolsRequiredFromPlatformRelease not returning discoveries * Enhanced handling of some discoveries states * Fix PackageManager reset * Add function to convert discovery.Port to rpc.Port * Moved reference argument parsing to new package * Fix functions docstrings * Remove duplicated code to initialize Sketch path * Add property conversion for platform not supporting pluggable discovery * Fix board list watch not working * Fix crash when converting Port to rpc struct * Add generic Port argument * Change gRPC upload functions to use new Port message * Add support for upload user fields * Fix upload unit tests * Fix code naming issues * Added builtin:mdns-discovery * Do not panic if discovery tool is not installed * Implemented port/protocol detection at CLI startup time * Perform 1200bps-touch only on serial ports * Added missing properties for pluggable upload * Correctly implemented 'board list' timeout option * Updated mdns-discovery to 0.9.2 * Add documentation * Add board properties to board list command and gRPC function * Fix documentation and code comments Co-authored-by:
-
- 20 Aug, 2021 1 commit
-
-
per1234 authored
Use of the major version ref will cause the workflow to benefit from ongoing development to its `actions/github-script` GitHub Actions action dependency at each patch or minor release up until such time as a new major release is made. Dependabot will submit a PR at that time, which will serve as the notification that a newer version is available. At that time, the maintainer should evaluate whether any changes to the workflow are required by the breaking change that triggered the major release before manually updating the major ref (i.e., `uses: actions/github-script@v5`).
-
- 17 Aug, 2021 1 commit
-
-
per1234 authored
* [skip changelog] Run relevant workflows on release branch creation The trunk-based development strategy is employed by this repository. This means that the release branch may contain a subset of the history of the default branch. The status of the GitHub Actions workflows should be evaluated before making a release. However, this is not so simple as checking the status of the commit at the tip of the release branch. The reason is that, for the sake of efficiency, the workflows are configured to run only when the processes are relevant to the trigger event (e.g., no need to run the Go unit tests for a change to the readme). In the case of the default branch, you can simply set the workflow runs filter to that branch and then check the result of the latest run of each workflow of interest. However, that was not possible to do with the release branch since it might be that the workflow was never run in that branch. The status of the latest run of the workflow in the default branch might not match the status for the release branch if the release branch does not contain the full history. For this reason, it will be helpful to trigger all relevant workflows on the creation of a release branch. This will ensure that each of those workflows will always have at least one run in the release branch. Subsequent commits pushed to the branch can run based on their usual trigger filters and the status of the latest run of each workflow in the branch will provide an accurate indication of the state of that branch. Branches are created for purposes other than releases, most notably feature branches to stage work for a pull request. Because the workflows are very comprehensive, it would not be convenient or efficient to run them on the creation of every feature branch. Unfortunately, GitHub Actions does not support filters on the `create` event of branch creation like it does for the `push` and `pull_request` events. There is support for a `branches` filter of the `push` event, but that filter is an AND to the `paths` filter and this application requires an OR. For this reason, the workflows must be triggered by the creation of any branch. The unwanted job runs are prevented by adding a `run-determination` job with the branch filter handled by Bash commands. The other jobs of the workflow use this `run-determination` job as a dependency, only running when it indicates they should via a job output. Because this minimal `run-determination` job runs very quickly, it is roughly equivalent to the workflow having been skipped entirely for non-release branch creations. This approach has been in use for some time already in the website deployment workflow. * [skip changlog] Simplify jobs run determination logic Co-authored-by:
Cristian Maglie <c.maglie@bug.st> Co-authored-by:
-
- 13 Aug, 2021 3 commits
-
-
per1234 authored
* [skip changelog] Use major version refs of action in "Test Go" workflow Use of the major version ref will cause the workflow to benefit from ongoing development to the actions up until such time as a new major release of an action is made, at which time we would need to evaluate whether any changes to the workflow are required by the breaking change that triggered the major release before updating the major ref (e.g., `uses: codecov/codecov-action@v3`). The previous pin to the patch version required an update to the workflow on every action release in order to keep it updated. * [skip changelog] Don't require Codecov upload success for test run in fork The "Test Go" workflow uploads code coverage data to Codecov. There will occasionally be spurious upload failures caused by transient network outages. These will typically succeed after the workflow is re-run, but the option to re-run is not offered when the workflow run passes. Because it's important that the data be complete, the `codecov/codecov-action` action is configured to fail the workflow run if the upload does not succeed. However, the upload will never be able to succeed for workflow runs in a fork where the owner has not set up Codecov. For this reason, the `fail_ci_if_error` input setting is made conditional upon the repository name. The result is: - Coverage data upload success is required for all workflow runs in the `arduino/arduino-cli` repository. - Uploads are attempted for workflow runs in forks (because the fork owner might have Codecov set up and want the data), but they are not required to succeed and will fail silently.
-
per1234 authored
* [skip changelog] Bring shell scripts into compliance with standard formatting A standardized style for all Arduino Tooling shell scripts has been established. The `.editorconfig` file is updated accordingly and all the repository's scripts made compliant with it. * [skip changelog] Sync install script with template We have assembled a collection of reusable project assets: https://github.com/arduino/tooling-project-assets These assets will be used in the repositories of all Arduino tooling projects. Some minor improvements and standardizations have been made in the upstream "template" installation script, and those are introduced to this repository via this pull request. Notable: - ShellCheck compliance - Support for specifying nightly build versions (e.g., "nightly-latest") via the script argument - Remove cryptic output not of interest to the user (likely forgotten debug artifacts from script development)
-
per1234 authored
We have assembled a collection of reusable GitHub Actions workflows: https://github.com/arduino/tooling-project-assets These workflows will be used in the repositories of all Arduino tooling projects. Some minor improvements and standardizations have been made in the upstream "template" workflow, and those are introduced to this repository via this pull request. Notable: - Replace changelog file read, deprecated `actions/create-release`, and asset upload steps with the comprehensive `ncipollo/release-action` action
-
- 12 Aug, 2021 5 commits
-
-
per1234 authored
* [skip changelog] Remove obsolete link footnotes from readme These have been replaced by more maintainable direct links. * [skip changelog] Sync "Publish Nightly Build" CI workflow with template We have assembled a collection of reusable GitHub Actions workflows: https://github.com/arduino/tooling-project-assets These workflows will be used in the repositories of all Arduino tooling projects. Some minor improvements and standardizations have been made in the upstream "template" workflow, and those are introduced to this repository via this pull request. Notable: - Improved failure reporting - Manual triggers to allow publishing on demand
-
per1234 authored
* [skip changelog] Sync "Check Python" CI workflow with template We have assembled a collection of reusable project assets: https://github.com/arduino/tooling-project-assets These assets will be used in the repositories of all Arduino tooling projects. Some minor improvements and standardizations have been made in the upstream "template" assets, and those are introduced to this repository here. Notable: - Check for black formatting style compliance - Update tool dependencies - Standardize linting task name and deprecate old task name - Add cyclomatic complexity check - Add pep8-naming plugin to flake8 * [skip changelog] Restore formatting compliance of Python code after black update After updating the black formatter tool, the new version wanted a small change in the Python formatting. * Remove obsolete Python linting task The sync with the template documentation assets has resulted in new standardized names for some of the tasks. The `python:check` task has been renamed to `python:lint`
-
per1234 authored
On every push and pull request that affects relevant files, check the protocol buffer files for code formatting inconsistency.
-
per1234 authored
The repository contains multiple Go modules. Previously, the CI workflow that lints and checks the formatting of the repository's Go code was only checking the primary module in the root of the repo. This workflow is now expanded to cover all Go code through the use of a dedicated matrix job for each of the modules. Arbitrary Go module paths can be specified to the tasks by defining 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.
-
per1234 authored
[skip changelog] Revert "Add skip changelog prefix to Dependabot workflow update commits (#1381)" (#1389) This reverts commit 4fbf7b7b. It turns out there is an undocumented maximum length of 15 characters for this prefix: https://github.com/arduino/arduino-cli/network/updates ``` Dependabot encountered the following error when parsing your .github/dependabot.yml: The property '#/updates/0/commit-message/prefix' was not of a maximum string length of 15 Please update the config file to conform with Dependabot's specification. ``` Unfortunately, even though it is possible to reduce the prefix length by 1 with the removal of the trailing space, we still end up with 16 characters.
-
- 11 Aug, 2021 5 commits
-
-
Matthijs Kooijman authored
The code tried to log the wrong error, which was nil, hiding the real error. This originally occurred for example when a version of the core was already installed manually in the sketchbook, and you would try to install another version using arduino-cli, though that has since been fixed (arduino-cli no longer tries to uninstall cores from the sketchbook). To still reproduce this problem, you can e.g. break the permissions of an installed core: $ arduino-cli core install arduino:avr@1.8.1 (...) $ chmod a-w ~/.arduino15/packages/arduino/hardware/avr/1.8.1 $ arduino-cli core install arduino:avr@1.8.2 Tool arduino:avr-gcc@7.3.0-atmel3.6.1-arduino5 already installed Tool arduino:avrdude@6.3.0-arduino17 already installed Tool arduino:arduinoOTA@1.3.0 already installed Downloading packages... arduino:avr@1.8.2 already downloaded Upgrading arduino:avr@1.8.1 with arduino:avr@1.8.2... Error upgrading platform: %!s(<nil>)... Error during install: upgrading platform: removing platform files: unlinkat /home/matthijs/.arduino15/packages/arduino/hardware/avr/1.8.1/firmwares: permission denied With this fix applied, this produces a proper error message: $ arduino-cli core install arduino:avr@1.8.2 Tool arduino:avr-gcc@7.3.0-atmel3.6.1-arduino5 already installed Tool arduino:avrdude@6.3.0-arduino17 already installed Tool arduino:arduinoOTA@1.3.0 already installed Downloading packages... arduino:avr@1.8.2 already downloaded Upgrading arduino:avr@1.8.1 with arduino:avr@1.8.2... Error upgrading platform: removing platform files: unlinkat /home/matthijs/.arduino15/packages/arduino/hardware/avr/1.8.1/firmwares: permission denied... Error during install: upgrading platform: removing platform files: unlinkat /home/matthijs/.arduino15/packages/arduino/hardware/avr/1.8.1/firmwares: permission denied -
dependabot[bot] authored
Bumps [pyyaml](https://github.com/yaml/pyyaml) from 5.3 to 5.4. - [Release notes](https://github.com/yaml/pyyaml/releases) - [Changelog](https://github.com/yaml/pyyaml/blob/master/CHANGES) - [Commits](https://github.com/yaml/pyyaml/compare/5.3...5.4) --- updated-dependencies: - dependency-name: pyyaml dependency-type: direct:production ... Signed-off-by:
dependabot[bot] <support@github.com> Co-authored-by:
dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
-
per1234 authored
The "gRPC reference" section of the documentation website is automatically generated from the repository's protocol buffer files. In order to make this generation process easy for developers to run, the necessary commands are defined in a task. For some reason, there were two tasks for this purpose, with different names and descriptions, but identical commands. This makes the taskfile more difficult to understand and more difficult to maintain. One of the tasks, `protoc:docs` is called by the `docs:generate` task. The other, `docs:gen:protobuf`, is not used or referenced anywhere in the repository. So I have removed `docs:gen:protobuf` from the taskfile.
-
per1234 authored
* [skip changelog] Sync testing infrastructure with "template" assets We have assembled a collection of reusable project assets: https://github.com/arduino/tooling-project-assets These will be used in the repositories of all Arduino tooling projects. Some minor improvements and standardizations have been made in the upstream "template" assets, and those are hereby introduced to this repository. Notable: - Configure paths filters to avoid unnecessary workflow runs - Increased parallelism - Improved maintainability * Remove obsolete testing tasks The sync with the template testing assets has resulted in new standardized names for some of the test runner tasks: - `test-unit` -> `go:test` - `test-integration` -> `go:test-integration` * [skip changelog] Update package names in imports As of Go 1.7 the `golang.org/x/net/context` package is available in the standard library under the name `context`. * [skip changelog] Tidy root module dependencies Result of running `go mod tidy` with Go 1.16.6. * [skip changelog] Tidy `github.com/arduino/arduino-cli/arduino/discovery/discovery_client` module's dependencies Result of running `go mod tidy` with Go 1.16.6. * [skip changelog] Tidy `github.com/arduino/arduino-cli/term_example` module's dependencies Result of running `go mod tidy` with Go 1.16.6. * [skip changelog] Tidy `github.com/arduino/arduino-cli/docsgen` module's dependencies Result of running `go mod tidy` with Go 1.16.6.
-
per1234 authored
* [skip changelog] Fix broken workflow link The GitHub Actions workflow used to deploy the documentation website was renamed to a filename more suitable for existence in a collection of reusable workflows that have multiple variations according to project requirements. The link to the file was not updated accordingly, which resulted it breaking. * [skip changelog] Move website versioning information out of CONTRIBUTING.md This content is for maintainers, and is not of interest to the average contributor. It makes an already overly long contributor guide even more overwhelming, and thus likely to be skipped. The documentation versioning and publishing system is now maintained in a centralized repository hosting a collection of reusable project assets. The documentation content previously located in CONTRIBUTING.md has all been migrated there and expanded. Since this is not high level contributor guidelines, it will be better to maintain it in a single place, linking to that documentation as needed.
-
- 10 Aug, 2021 3 commits
-
-
per1234 authored
* [skip changelog] Sync documentation assets with templates We have assembled a collection of reusable project assets: https://github.com/arduino/tooling-project-assets These assets will be used in the repositories of all Arduino tooling projects. Some significant improvements and standardizations have been made in the upstream "template" assets, and those are introduced to this repository here. Notable: - Use markdownlint to check for common problems and formatting. - Make link check task Windows compatible - Streamline website versioning system - Use modern MkDocs versioning features - Make command reference generation task Windows compatible - Consolidate all Python dependency management to Poetry - Standardize documentation-related task names and deprecate old task names * Remove obsolete documentation tasks The sync with the template documentation assets has resulted in new standardized names for some of the documentation management tasks: - `docs:gen:commands` -> `go:cli-docs` - `docs:gen` -> `docs:generate` - `docs:build` -> `docs:check` - `docs:serve` -> `website:serve` - `docs:check-links` -> `markdown:check-links` * [skip changelog] Use standard list prefix in Markdown This is the standardized ordered list prefix for use in all Arduino Tooling Markdown files. The Markdown renderer will automatically handle numbering. Manual numbering means that either all following list items need to be renumbered every time a list item is added or removed, resulting in more work for contributors and reviewers. * [skip changelog] Use standardized Markdown code block style "Code fencing" is superior to the indentation code block syntax of Markdown because it permits syntax highlighting. Even in cases where syntax highlighting is not applicable, a consistent style should be used throughout all the Markdown files of Arduino Tooling projects.
-
Cristian Maglie authored
* Update github.com/miekg/dns lib to v1.1.43 * fix go.sum in docsgen folder * fix go.sum in client_example folder
-
per1234 authored
* [skip changelog] Sync general formatting check workflow with template We have assembled a collection of reusable GitHub Actions workflows: https://github.com/arduino/tooling-project-assets These workflows will be used in the repositories of all Arduino tooling projects. The Prettier formatting tool is used in the tasks for formatting and checking the formatting of the repository's Markdown and YAML files. Prettier supports a long list of other languages. There is no reason not to take advantage of those capabilities as well, so the new workflow applies it to all supported files. Several of the tasks have been deprecated in favor of the new `general:format-prettier` task: - `docs:check` - `docs:format` - `config:check` - `config:format` These still work as before, but they now display a deprecation warning. * Remove superfluous formatting tasks These are replaced by the `general:format-prettier` task. Even though that doesn't provide a formatting compliance check, the developer doesn't have any need for such a thing, since they will be better off to simply format, and the CI now takes the approach of formatting and then failing if it produced a diff. * [skip changelog] Bring all files into Prettier formatting style compliance Previously, Prettier was only run on the Markdown and YAML files. With the new expanded scope of Prettier coverage, the JSON files are now required to be compliant.
-
- 09 Aug, 2021 1 commit
-
-
per1234 authored
Dependabot is configured to submit pull requests for updates to the GitHub Actions actions used in the repository's workflows whenever a new version is available. These commits will not result in any user facing changes and so should not be mentioned in the release changelog. The changelog generation system automatically excludes any commit that has the `[skip changelog]` prefix on its message title. Adding this changelog to the commits generated by Dependabot will save the release manager time when cleaning up the raw changelog.
-
![dependabot[bot]'s avatar](https://www.gravatar.com/avatar/48ea49be76d0c68403a7f3df87e3487d?s=80&d=identicon "dependabot[bot]")