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>
A Docker container is used to produce the Linux build of Arduino IDE.
The dependencies of the build are pinned to a specific version in the Dockerfile in order to ensure a stable environment
in the images.
One such dependency is Git. The version of Git available from the package repository of the Ubuntu 18.04 distro used for
the image is too outdated to be used for this purpose. For this reason, a PPA is used as the source for the Git package.
Unfortunately the maintainers of the PPA remove the previous package every time they add a package for a newer version
of Git. This breaks the version pinned installation of the Git package:
5.515 E: Version '1:2.42.0-0ppa1~ubuntu18.04.1' for 'git' was not found
For this reason it is necessary to unpin Git in the Dockerfile. This will cause whichever version is available from the
PPA to be installed each time the image is built. Although not ideal for this application, that shouldn't cause any
problems in practice since Git has quite a stable and carefully maintained interface.
Unfortunately the latest v5 version of the actions/setup-go action used to set up the Go programming language 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 actions/setup-go@v4 for the Linux build job. We will receive pull requests from
Dependabot offering to update this outdated action dependency for 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 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.
The "Arduino IDE" GitHub Actions workflow uses a Docker container for the build job of certain target, while running others directly in the
runner environment.
Due to differences between these two environments, some steps must run only when a container is used by the job, and others only when the job is running in the runner environment. This is done by a conditional on the job matrix data regarding the container. The container value is set to null for the jobs that run in the runner environment, while containing a full container configuration mapping for the jobs that run in a container.
Previously the conditional unnecessarily used the value of the image key of the container object specifically. The comparison
can be done against the container value itself. Doing this will make it a little easier to understand the workflow code, since the conditional more clearly reflects the matrix (where `container` is set to `null` instead of `container.image`).
Python 3.12.x is incompatible with the current version of node-gyp (9.4.0). For this reason, it is necessary to
configure the "GitHub Actions" workflow to use the compatible Python 3.11.x until the next release of node-gyp (which
should contain a fix for the breakage) is made.
In addition to the builds, when a nightly or production release is published, a "channel update info file" is also
uploaded to Amazon S3 by the "Arduino IDE" GitHub Actions workflow. The IDE checks the channel file on the server to get
information about available updates.
Previously the Linux production release builds were being remade manually due to the ones produced by GitHub Actions not
being compatible with older distro versions due to a dynamically linked dependency. For this reason, a step was
temporarily added to the workflow to cause it to not upload the Linux channel file in order to avoid Linux users from
receiving an update offer before the limited compatibility automated build had been replaced with the manually produced
build.
The automated build system has been adjusted to produce Linux builds with the intended range of compatibility, but the
step that deleted the channel file was not removed at that time. The obviated step is hereby removed in order to allow
complete releases to be published by the workflow.
The "Arduino IDE" GitHub Actions workflow is used to generate several distinct types of builds:
- Tester builds of commits
- Nightly builds
- Release builds
Different actions must be performed depending on which type of build is being produced. The workflow uses dedicated jobs
for publishing the nightly builds and for publishing the release builds. Those jobs are configured to run only when
certain criteria are met.
One such criteria is that the merge-channel-files job ran as expected. There are four possible result types of a job,
which should be handled as follows:
| Result | Run dependent job? |
| -------- | ------------------ |
| success | Yes |
| failure | No |
| canceled | No |
| skipped | Yes |
GitHub Actions automatically takes the desired action regarding whether the dependent job should run for the first three
result types, but that is not the case for the "skipped" result. The merge-channel-files job dependency is skipped when
a channel file merge is not needed and so this is not cause to cancel the build publishing.
The only way to make a dependent job run when the dependency was skipped is to add the `always()` expression to the job
conditional. This goes too far in the other direction by causing the job to run even when the dependency failed or was
canceled. So it is necessary to also add logic for each of the dependency job result types to the conditional, which
makes it quite complex when combined with the logic for the other criteria of the job.
In order to reduce the amount of complexity of the conditionals of the dependent jobs, a job was interposed in the
dependency chain, which was intended to act simply as a container for the logic about the merge-channel-files job
result. Unfortunately it turns out that even if the direct dependency job's result was success, if any ancestor in the
dependency chain was skipped, GitHub Actions still skips all dependent jobs without an `always()` expression in their
conditional, meaning the intermediate job was pointless. This caused the build publishing jobs to be skipped under the
conditions where they should have ran.
The pointless intermediate job is hereby removed, an `always()` expression added to the conditionals of the dependent
jobs, and the full logic for how to handle each dependent job result type added there as well.
