GitLab

* fix a regression introduced in be5022e0. `--input` flags were ignored
partially revert "refactor sketch path calculation" in `upload.go`

* fix test after f85513c6

* use `WarnDeprecatedFiles` to remove some code duplication

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

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