GitLab

[breaking] uniform cli commands and flag

[breaking] replace `board attach <port|fqbn> <sketch-path>` with `board attach -b <fqbn> | -p <port> <sketh-path>`

move `DetectSkipPostInstallValue` in arguments package
create `PostInstallFlags` struct in arguments package
remove `listFlags` struct

* Clean up some useless constants
* made legacy/builder.go independent from legacy/constants
* Now 'compile --only-compilation-database' will run all pre-* hooks

Some platforms make sketch preparation see #1547

Fix #1547
Co-authored-by: per1234 <accounts@perglass.com>

This method allows to bound process execution to a context.

Unlike the IDE and Web Editor, Arduino CLI is intended to be used directly only by advanced users. However, all types of
users are likely to visit the repository and documentation website. Some of these readers will not be familiar with the
meaning of the acronym "CLI".

The previous documentation introduces Arduino CLI as:

> an all-in-one solution that provides [wonderful things] to use any Arduino compatible board and platform

Which sounds like something every Arduino user would be interested in.

Those readers might therefore get the impression this is some sort of GUI application like the IDE and be frustrated and confused
after spending time to install and run the program, only to find that it doesn't apparently do anything when they run the
executable (because they did it from a file browser or shortcut).

It is a bit difficult to describe Arduino CLI's interface in a short introduction because, despite the "CLI" in the name,
command line is only one of the interfaces offered by Arduino CLI (the others being the gRPC and Go APIs). I added the
term "machine" to cover the others.

* Add an introduction to install docs

This document provides a list of installation options. The user may pick any one option that is most convenient for them.
However, a reader might get the impression that it is a list of instructions that must be followed from top to bottom.

An introduction makes the situation immediately clear to the reader.

* Clarify that sh is not required in template install docs

A significant portion of Arduino users use Windows. The first option listed in the installation instructions is for an
installation shell script, which can be used on Windows, but might not be convenient for some Windows users.

This could be discouraging or frustrating to potential new users, but not necessarily so because the script is an
optional convenience and directly downloading and installing the tool is also an option, as documented in the
instructions for the second listed option.

A little refinement of the wording of the script's `sh` requirement makes the situation clear to those users.

* Add a reference link re: PATH to install docs

A reference link provides easy access to the relevant information for readers who are not familiar with this concept
while not harming readability for everyone else by increasing verbosity.

* Align heading levels in install docs

This document is intended to provide a list of installation options:

- brew
- script
- download
- build

but the heading levels were misaligned, which resulted in this structure:

-brew
- script
  - download
  - build

* fix packages being added to the package manager even if they were not respecting the specification

* add test to check if if the bug it's fixed

* fix platform release being nil and causing panic with indexes not compliant with specs

* add test to check if the bug is fixed

* add comments and optimize the code a little bit

* Apply suggestions from code review
Co-authored-by: per1234 <accounts@perglass.com>
Co-authored-by: per1234 <accounts@perglass.com>

* Split CI execution of integration tests

* Make Github workflows runners cry

* Different approach

* Moved errors to arduino package

* Handled package name change cause of errors move

* Renamed some errors

* Add CI workflow to check for unapproved Go dependency licenses

A task and GitHub Actions workflow are provided here for checking the license types of Go project dependencies.

On every push and pull request that affects relevant files, the CI workflow will check:

- If the dependency licenses cache is up to date
- If any of the project's dependencies have an unapproved license type.

Approval can be based on:

- Universally allowed license type
- Individual dependency

* Make initial commit of dependency license metadata

The  folder contains a cache of license metadata for all the project's Go dependencies. This serves two purposes:

- Allow the Licensed dependency license checker tool to only check licenses when a dependency is added or updated

- Allow the maintainer to manually define license metadata when the licensee tool is unable to automatically detect it

* Manually define dependency license metadata that was not detected

The "Licensed" dependency license checker tool uses the licensee tool to automatically determine the license type based
on metadata provided by the dependency author. This must be in a standardized format without any modifications. In cases
where that wasn't done, it is necessary to determine the license type and update the dependency license metadata cache in
the `.licenses` folder manually.

The Licensed tool will check this data whenever the dependency version is updated to make sure the license hasn't changed.

* Fixed network upload for avr packages

* Added test for serial pluggable-monitor compatibility conversion

* Added data for unit testing

* Fixed other collateral tests

* Perform regexp compile at package level

* fix i18n

* [skip changelog] Standardize license file

Standardization in license documentation is important because, in addition to making it easy for humans to find this vital information, it allows machines to automate the process of license type determination, which is useful both for discovering suitable open source projects as well as checking open source license compliance.

The open source license of Arduino CLI is already stored in a standardized location at `/LICENSE.txt`. However, even though Arduino CLI is licensed under the industry standard GPL 3.0 open source license, additional text was added to the license file which offers the option to purchase an exception for proprietary use of the code. Even though this offer does not have any legal effect on the GPL 3.0 license, it does make it so that the license file can no longer be identified with 100% confidence by machines as GPL 3.0, which means a human must make that identification instead.

Since there is no need to place the exception offer in the license file, it can be moved to the readme and the license file left as the verbatim GPL 3.0 license text, as looked for by the license type detection tools such as licensee.

* Add CI workflow to check the license file

Whenever one of the recognized license file names are modified in the repository, the workflow runs to check whether the license can be recognized and whether it is of the expected type.

GitHub has a useful automated license detection system that determines the license type used by a repository, and surfaces that information in the repository home page, the search web interface, and the GitHub API. This license detection system requires that the license be defined by a dedicated file with one of several standardized filenames and paths.

GitHub's license detection system uses the popular licensee tool, so this file also serves to define the license type for any other usages of licensee, as well as to human readers of the file.

For this reason, and to ensure it remains a valid legal instrument, it's important that there be no non-standard modifications to the license file or collisions with other supported licence files. This workflow ensures that any changes which would change the license type or which license file is used by the detection are caught automatically.

* Free contributors from i18n data sync responsibility

* Update .github/workflows/check-i18n-task.yml
Co-authored-by: per1234 <accounts@perglass.com>
Co-authored-by: per1234 <accounts@perglass.com>