- 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.
The sketch cache might be empty, when trying to generate
the secrets include in the main sketch file from the
`secrets` property.
Closes#1999
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
In Theia, the theme ID is not always in sync with the persisted
`workbench.colorTheme` preference value. For example, one can preview a
theme with the `CtrlCmd+K` + `CtrlCmd+T` key chords. On quick pick
selection change events, the theme changes, but the change is persisted
only on accept (user presses `Enter`).
IDE2 has its own way of showing and managing different settings in the
UI. When the theme is changed from outside of the IDE2's UI, the model
could get out of sync. This PR ensures that on `workbench.colorTheme`
preference change, IDE2's settings model is synchronized with persisted
Theia preferences.
Closes#1987
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
- updated to `electron-builder@23.6.0`
- set `CSC_FOR_PULL_REQUEST` env to run notarization for a PR build.
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
