The "build" workflow builds the application for a range of target hosts. This is done by using a job matrix. A separate
parallel job runs for each target. The target-specific configuration data is defined in the job matrix array.
This configuration data includes the information related to the code signing certificates. Inexplicably, during the work
to add support for signing the Windows builds with an "eToken" hardware authentication device, this data was not used
for the Windows code signing configuration. Instead the certificate data was redundantly hardcoded into the workflow
code.
The Windows code signing certificate configuration is hereby changed to use the established flexible job configuration
data system. This makes the workflow easier to understand and maintain.
The Windows builds of the application are cryptographically signed. The signing requires an "eToken" hardware
authentication device be connected to the machine performing the signing. This means that it is necessary to use a
self-hosted GitHub Actions runner for the Windows job of the build workflow rather than the runners hosted by GitHub.
There are some unique characteristics of the self-hosted runner which the workflow code must accommodate. One of these
is that, rather than installing dependencies of the build process during the workflow run as is done for the
GitHub-hosted runners, the dependencies are preinstalled in the self-hosted runner machine. So the dependency
installation steps must be configured so that they will be skipped when the job is running on the self-hosted runner.
This is done by adding a conditional to the steps. Previously the conditional was based on the value of the `runner.os`
context item. This is not an appropriate indicator of the job running on the self-hosted runner because `runner.os` will
have the same value if the job was running on a GitHub-hosted Windows runner. That might seem like only a hypothetical
problem since the workflow does not use a GitHub-hosted Windows runner. However, it is important to support the use of
the workflow in forks of the repository. In addition to the possible value to hard forked projects, this is essential to
allow conscientious contributors to test contributions to the build and release system in their own fork prior to
submitting a pull request.
The conditionals are changed to use the more appropriate indicator of the specific name of the self-hosted Windows
runner (via the `runner.name` context item).
The Windows builds of the application are cryptographically signed. The signing requires an "eToken" hardware
authentication device be connected to the machine performing the signing. This means that it is necessary to use a
self-hosted GitHub Actions runner for the Windows job of the build workflow rather than the runners hosted by GitHub.
There are some unique characteristics of the self-hosted runner which the workflow code must accommodate. The default
working directory of the self-hosted runner is not suitable to perform the build under because the the resulting folder
structure produced paths that exceeded the ridiculously small maximum path length of Windows. So the workflow must be
configured to use a custom working directory with a short path (`C:\a`).
This custom working directory must be used only for the job running on the self-hosted Windows runner so the working
directory of the relevant workflow steps are configured using a ternary expression. Previously, this expression had
multiple conditions:
* the value of the `runner.os` context item
* the definition of a custom working directory value in the job matrix
The second condition is entirely sufficient. The use of the first condition only added unnecessary complexity to the
workflow code, and imposed a pointless limitation of only allowing the use of the custom working directory system on
Windows runners.
Removing the unnecessary condition makes the workflow easier to understand and maintain, and makes it possible to
configure any job to use a custom working directory if necessary.
The build workflow produces builds for a range of target host architectures, including macOS Apple Silicon. This is done
by running a native build in a machine of the target architecture.
At the time the support for producing Apple Silicon builds was added to the workflow, use of GitHub-hosted Apple Silicon
runner machines was charged by the minute (while use of the other runners is free). In order to avoid excessive
expenses, the workflow was configured so that the Apple Silicon builds were only produced when absolutely necessary.
This was done by defining two sets of job matrix arrays, one for jobs using free runners, and the other for jobs using
paid runners. Due to the limitations of the GitHub Actions framework, it was necessary to use workflow environment
variables for this purpose.
Since that time, GitHub made free GitHub-hosted Apple Silicon runners available. When the workflow was adjusted to use
that runner, the configuration for the Apple Silicon build job was moved to the free runner job matrix array. The system
for supporting selective use of paid GitHub-hosted runners to produce builds was not removed at that time. This is
reasonable since it is possible the need will arise for using paid runners at some point in the future (e.g., only
legacy older versions of free macOS "Intel" runners are now provided and it is likely that even these will eventually be
phased out forcing us to use the paid runner to produce builds for that target). However, the environment variable for
the paid runner job matrix array data was removed. The absence of that variable made it very difficult to understand the
workflow code for the system.
For this reason, the environment variable is replaced, but empty of data. A comment is added to explain the reason for
this.
Document prerequisites of the Arduino CLI, LS, etc. tools when built
from a Git commitish.
---------
Signed-off-by: dankeboy36 <dankeboy36@gmail.com>
Co-authored-by: per1234 <accounts@perglass.com>
On every startup, Arduino IDE checks for new versions of the IDE. If a newer version is available, a notification/dialog
is shown offering an update.
"Newer" is determined by comparing the version of the user's IDE to the latest available version on the update channel.
This comparison is done according to the Semantic Versioning Specification ("SemVer").
In order to facilitate beta testing, builds are generated of the Arduino IDE at the current stage in development. These
builds are given an identifying version of the following form:
- <version>-snapshot-<short hash> - builds generated for every push and pull request that modifies relevant files
- <version>-nightly-<YYYYMMDD> - daily builds of the tip of the default branch
In order to cause these builds to be correctly considered "newer" than the release version, the version metadata must be
bumped immediately following each release.
This will also serve as the metadata bump for the next release in the event that release is a minor release. In case it
is instead a minor or major release, the version metadata will need to be updated once more before the release tag is
created.
Status object thrown by grpc commands contains metadata that needs to be serialized in order to map it to custom errors generated through proto files https://github.com/grpc/grpc-web/issues/399
* fix: use `@pingghost/protoc` to compile proto files
The npm package previously used (`protoc`) is still lacking apple arm32 support, see https://github.com/YePpHa/node-protoc/pull/10
* feat: use Arduino CLI 1.0.4
* fix: allow use of node16 in github actions
* chore: update `arduino-language-server` version for cli-1.0.0
* fix: deprecated platform order test
Arduino deprecated platforms should have more priority then other deprecated ones
An empty object (`{}`) must be used to correctly unset the CLI config
value to its default.
Closesarduino/arduino-ide#2184
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
Use customized `PanelLayout#removeWidget` and
`PanelLayout#insertWidget` logic for the layout
updates. The customized functions ensure no side
effect if adding/removing the widget to/from the
layout but it's already present/absent.
Unlike the default [`PanelLayout#removeWidget`](9f5e11025b/packages/widgets/src/panellayout.ts (L154-L156))
behavior, do not try to remove the widget if it's
not present (has a negative index). Otherwise,
required widgets might be removed based on the
default [`ArrayExt#removeAt`](9f5e11025b/packages/algorithm/src/array.ts (L1075-L1077))
behavior.
Closes: arduino/arduino-ide#2354
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
Unfortunately the latest v2 version of the arduino/setup-task action used to install the Task task runner tool in the
runner machine has a dependency on a higher version of glibc than is provided by the Linux container. For this reason,
the workflow is configured to use arduino/setup-task@v1 for the Linux build job.
We will receive pull requests from Dependabot offering to update this outdated action dependency at each subsequent
major version release of the action (which are not terribly frequent). We must decline the bump of the action in that
specific step, but we can accept the bumps of all other usages of the action in the workflows. Dependabot remembers when
you decline a bump so this should not be too bothersome.
Added a new preference (`arduino.language.asyncWorkers`) to control the
number of async workers used by `clangd`.
Users can fine tune the `clangd` thread count to overcome the excessive
CPU usage.
Use 0.1.2 Arduino Tools VSIX in IDE2.
Ref: arduino/arduino-language-server#177
Ref: arduino/vscode-arduino-tools#46
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
A separate build of Arduino IDE is produced for each of the macOS host architectures:
* Apple Silicon (ARM)
* Intel (x86)
The Arduino IDE distribution includes several bundled helper tools. The build of those tools should also be selected according to the target host architecture.
At the time the infrastructure was set up for bundling the "Arduino Firmware Uploader" tool with the Arduino IDE distribution, that tool was only produced in a macOS x86 variant. So this was used even in the Apple Silicon Arduino IDE distribution, relying on Rosetta 2 to provide compatibility when used on Apple Silicon machines. Since that time, the Arduino Firmware Uploader build infrastructure has been updated to produce an Apple Silicon build of the tool and such a build is available for the IDE's current version dependency of Arduino Firmware Updater.
The "Arduino Firmware Uploader" tool bundling script is hereby updated to use the most appropriate variant of the dependency for the target host architecture. This provides the following benefits
* Compatibility with systems that don't have Rosetta 2 installed
* Improved performance
The Arduino IDE installation includes a collection of example sketches demonstrating fundamental concepts.
These examples are hosted in a dedicated repository, which is a dependency of this project. A new release has been made
in that `arduino/arduino-examples` repository.
The infrastructure for downloading the examples during the Arduino IDE build is hereby updated to use the latest release
of the `arduino/arduino-examples` repository.
The Save As operation is halted and the problem clearly communicated to
the user when there is a collision between the target primary source
file name and existing secondary source files of the sketch.
Closes#827
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
This commit rewrites how IDE copies sketches as part of the _Save As_
operation. Instead of copying to the destination, IDE copies the sketch
into a temporary location, then to the desired destination.
This commit drops [`cpy`](https://www.npmjs.com/package/cpy).
Ref: 47b89a70b5Closes#2077
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
Use a fallback frontend app config when starting IDE2 from an ino file
(from Explorer, Finder, etc.) and the app config is not yet set.
Closes#2209
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
- Can pick a programmer if missing,
- Can auto-select a programmer on app start,
- Can edit the `launch.json`,
- Adjust board discovery to new gRPC API. From now on, it's a client
read stream, not a duplex.
- Allow `.cxx` and `.cc` file extensions. (Closes#2265)
- Drop `debuggingSupported` from `BoardDetails`.
- Dedicated service endpoint for checking the debugger.
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
