Some Arduino boards have a supplemental hardware module that provides functionality separate from the primary
microcontroller the sketch program runs on.
Enhancements or fixes to the firmware that runs on these supplemental modules may be made over time so it is important
for the users of these boards to have an easy way to update the firmware. Arduino IDE provides a tool for doing this.
At the time the tool was created, the poor choice was made to include the names of the specific modules it supported at
the time in the tool's name. As was inevitable, that list has changed, rendering the tool name no longer accurate.
The immediate problem is that support has been added for updating the "bridge" and radio module on the UNO R4 WiFi. That
module is neither a "WiFi101" nor a "NINA", so the tool name does not reflect the support for the UNO R4 WiFi.
More significant changes in the supported modules are under way and will be introduced in the next release:
- Dropping support for the "WiFi101" module
- Adding support for the module on the Portenta C33 board
Rather than attempting to maintain a regularly changing and overly verbose name that includes the list of every
supported module, it is better to use a name for the tool that only describes its general purpose, leaving the task of
describing the specific supported modules to the documentation.
The project was recently switched to using a "trunk-based" development strategy. This necessitated some adjustments to
the configuration of the GitHub Actions workflows in order to ensure the CI system could be used to effectively validate
the project at the state staged for release in the release branch.
A `run-determination` job was added to the workflow. This job determines whether the conditions under which the workflow
was triggered indicate that the rest of the jobs in the workflow should be run.
A validation workflow should run fully under any of the following conditions:
- The trigger event was something other than a branch creation
- The trigger event was a release branch creation
Since the project is fully validated prior to a release, running the workflow when triggered by a release tag is
pointless (and even harmful in some specific standardized workflows not currently used in this repository), so (even if
for no other reason than efficiency) verification workflows are configured to not run under these conditions.
The standardized Arduino tooling workflows follow a modular design where each workflow has a narrow scope of purpose.
That path was not taken by those who set up the infrastructure for this repository. They instead created a single
massive monolithic "Arduino IDE" workflow that performs many unrelated operations under various conditions. This workflow generates
releases in addition to doing validation. Even though it is pointless to run the workflow's validation operations when
the workflow is triggered by a release tag, it is essential to run it for the release generation.
Previously, the code used in the "Arduino IDE" workflow's `run-determination` job was configured as appropriate for a
verification workflow. This meant that a release would not be generated on push of a release tag as intended. The bug is
fixed by adjusting the code to do a full run of the workflow when triggered by a release tag.
Before arduino/arduino-cli#488, IDE2 required a way to stop the daemon
process if the parent (backend) process crashed. However, this mechanism
is no longer necessary as the CLI daemon process is not actually a true
daemon process.
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
Use a `string` array of command flags instead of the concatenated final
`string` command.
Ref: arduino/arduino-ide#2067Closesarduino/arduino-ide#2179
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
- update Theia to `1.39.0`,
- remove the application packager and fix the security vulnerabilities,
- bundle the backed application with `webpack`, and
- enhance the developer docs.
Co-authored-by: Akos Kitta <a.kitta@arduino.cc>
Co-authored-by: per1234 <accounts@perglass.com>
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
The localization of the UI strings specific to the Arduino IDE application is done via the Transifex localization
platform. A scheduled workflow pulls the data from Transifex weekly and submits a pull request for the updates.
Previously, the script used to pull the data did not clean the data files before pulling. This meant that a vestigial
file would accumulate in the repository whenever a language was removed from the Transifex project.
The accumulation is avoided by deleting the data files for the locales managed on Transifex (all locales other than the
source English locale) before downloading the data from Transifex.
This will add a "中文(繁體)" option to the "Language" menu in the Arduino IDE preferences, which will cause the strings
in the IDE UI to be localized for "Chinese (Traditional)".
In addition to the translations for the strings that originate from the Eclipse Theia IDE framework provided by the
"Chinese (Traditional) Language Pack for Visual Studio Code" language pack, this will also utilize the translations of
the Arduino IDE-specific strings contributed by the community.
Added a new preference (`arduino.monitor.dockPanel`) to specify the
location of the application shell where the _Serial Monitor_ widget
resides. The possible values are `"bottom"` and `"right"`. The default\
value is the `"bottom"`.
The dock panel is per application and not per workspace or window.
However, advanced users can create the `./.vscode/settings.json` and
configure per sketch preference.
Signed-off-by: dankeboy36 <dankeboy36@gmail.com>
- In the bundled application, the customized logger that writes the log
files bogusly includes only the first message fragment in the log
message. This PR ensures all message fragments are included in the final
message before it is printed to the console/terminal and persisted to
the rotating log files.
- Includes messages with `debug` severity in the log.
- Disables the ANSI coloring in the CLI daemon log by adding the
`NO_COLOR=true` environment variable to the spawned CLI daemon process.
- Trims trailing line ending of the daemon log.
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
- Update a shared state on fqbn, port, sketch path, and etc. changes.
VS Code extensions can access it and listen on changes.
- Force VISX activation order: API VSIX starts first.
Signed-off-by: dankeboy36 <dankeboy36@gmail.com>
Previously, releases were always made from a point in the revision history of the `main` branch (typically the tip of
the branch at the time of the release). Although the simplicity of this approach is nice, it can be limiting in some
cases. For this reason, the project is switching to using a "trunk-based" development strategy, as described here:
https://trunkbaseddevelopment.com/
This approach allows making releases at any time that consist of the arbitrary subset of revisions suitable for shipping
to the users at that time. The commits that should be included in the release are cherry-picked to a release branch and
the tag created on that branch.
This means that:
- PRs can be merged to the `main` branch as soon as they have passed review rather than having to postpone the merge of
changes that are not ready to be included in the next release.
- Releases don't need to be postponed if the prior revision history on the `main` branch contains changes that are not
ready to be included in the release.
The documented release procedure must be adjusted to reflect the new development strategy.
CI System Adjustments
---------------------
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 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.
Due to the comprehensive nature of this project's CI system, it would not be convenient or efficient to fully run all CI
workflows 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 while 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.
Happens when the IDE2 backend process crashes, and the communication
drops between the client and the server.
Closes#2081
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
The previous logic has incorrectly bailed the save when there is no
Internet connection. The corrected logic disallows saving files if there
is no connection between the frontend and the backend.
Ref: cff2c956845e04d320231e8a924d1a47ad016af7
Closes#2079
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
Previously, if the `port` was not set in IDE2, the compile request
object has been created with an empty port object (`{}`). From now on,
if the port is not specified, IDE2 will create a compile request with
the default `null` `port` value.
Closes#2089
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
It should make integration tests more resilient on the Windows CI.
From now on, tests are not starting a daemon to initialize the
`directories.data` folder for the test suites but rely on the raw
command. It is required to avoid spawning the discovery processes, which
cannot be terminated on Windows while the daemon is up and running.
Closes#2059
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
- Updated `@theia/*` to `1.37.0`.
- Fixed all `yarn audit` security vulnerabilities.
- Updated to `electron@23.2.4`:
- `contextIsolation` is `true`,
- `nodeIntegration` is `false`, and the
- `webpack` target is moved from `electron-renderer` to `web`.
- Updated to `typescript@4.9.3`.
- Updated the `eslint` plugins.
- Added the new `Light High Contrast` theme to the IDE2.
- High contrast themes use Theia APIs for style adjustments.
- Support for ESM modules: `"moduleResolution": "node16"`.
- Node.js >= 16.14 is required.
- VISX langage packs were bumped to `1.70.0`.
- Removed undesired editor context menu items. (Closes#1394)
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
Changed the `source` and `cwd` args to avoid accidentally creating an
invalid `glob` patterns when doing the brace expansion by `cpy`.
Closes#2043
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
PROEDITOR-50: error markers have been disabled for built-ins (daedae1).
Relaxed the error marker filtering for cloud sketches.
Closes#669
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
- Copied the env-variable server from Theia and made it possible to
customize it for the tests. Each test has its own `data` folder.
- Relaxed the primary package and library index error detection.
This should make the init error detection locale independent.
- Kill the daemon process subtree when stopping the daemon.
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
Arduino IDE comes with a selection of officially maintained and supported built-in themes:
- Light
- Dark
- High Contrast
Although these three should be sufficient for most users, some users may have other requirements or preferences for the
Arduino IDE UI theming. Fortunately, because it is built on the Eclipse Theia IDE framework, Arduino IDE supports VS
Code theme extensions. This makes a large variety of 3rd party themes available to the user, and even the ability to
create custom themes.
Instructions for installing VS Code theme extensions are here added to the "Advanced Usage" document hosted in the
repository.
Arduino IDE offers an update to the user when a newer version is available. The availability of an update is determined
by comparing the user's IDE version against data file ("channel update info file") stored on Arduino's download server.
These "channel update info files" are automatically generated by the build workflow.
Previously the release process was fully automated, including the upload of the "channel update info files" to the
server.
As a temporary workaround for limitations of the GitHub Actions runner machines used to produce the automated builds,
some release builds are now produced manually:
- Linux build (because the Ubuntu 18.04 runner was shut down and newer runner versions produce builds incompatible with
older Linux versions)
- macOS Apple Silicon build (because GitHub hosted Apple Silicon runners are not available)
The automatic upload of the "channel update info files" produced by the build workflow is problematic because if users
receive update offers before the "channel update info files" are updated for the manually produced builds, they can
receive an update to a different build than intended:
- Users of older Linux versions would update to a build that won't start on their machine
- macOS Apple Silicon users would update to macOS x86 build that is less performant on their machine
For this reason, the build workflow is adjusted to no longer upload the Linux and macOS "channel update info files" to
the download server on release. These files will now be manually uploaded after they have been updated to provide the
manually produced builds.
This workaround will be reverted once a fully automated release system is regained.
