The Arduino company is no longer soliciting monetary donations. Community members who wish to contribute to the project
still have opportunities to do so via the other options listed here.
The system used for localization of this project leverages the infrastructure and data that already exists for VS Code.
These assets are applicable to Arduino IDE 2.x due to the project being built on the Eclipse Theia IDE framework. In
this way, the Arduino IDE developers and community are only responsible for internationalization and localization of the
Arduino-specific strings (e.g., "Sketchbook") used in the IDE's UI.
The unfortunate downside to this approach is that there is a hard technical limit on localization of the project to
languages for which a VS Code "language pack" is available.
It will be helpful to clearly communicate the set of languages for which we are able to ship contributions from
translators.
Likewise, it will be useful to also communicate that, we are able to ship contributions of translations of Arduino CLI
user interface strings for any language. This is due to the fact that the Arduino CLI codebase uses a completely
different internationalization system that does not impose any technical limits on the scope of localization.
* Trim trailing whitespace in build workflow
* Give build workflow step access to required deployment environment
Certain operations in the "Arduino IDE" GitHub Actions workflow use GitHub Actions "secrets" which are defined in the
repository's administrative settings.
These secrets will typically not be defined when the workflow is run in a fork. However, the workflow's base
functionality, the automated building of the application, does not require secrets. Since that base functionality alone
is very useful to contributors (either to validate relevant changes to the application and infrastructure, or to
generate tester builds) who are performing development work in a fork. For this reason, the workflow is configured to
only perform the secret-dependent operations when the required secrets have been defined in the repository settings.
One such operation is publishing the generated builds to Amazon S3, which Arduino uses to host files for distribution.
This operation depends on the "AWS_ROLE_ARN" secret. As a security measure, this secret is defined inside a deployment
environment (named "production"). GitHub Actions workflow jobs can only use secrets from deployment environments which
they have been explicitly configured to have access to.
At the time the workflow was originally developed, GitHub did not have the deployment environment feature, and so the
workflow was not configured to use environments. The switch to using a deployment environment for this secret was made
only recently, and when that was done, the workflow job that checks whether the secret is defined was not configured to
have access to the "production" environment. This caused the workflow to think it was running in a context where that
secret is not defined even when the secret is in fact defined. The bug caused the workflow to always spuriously skip the
"publish" job which publishes nightly builds of Arduino IDE, and the "publish release" step which publishes production
releases.
The bug is fixed by configuring the "build-type-determination" job so that it has access to the "production"
environment.
* fix(plugin): decouple state update from the LS
To enhance the reliability of Arduino IDE extensions, the update
process for `ArduinoState` has been modified to ensure independence
from the language server's availability. This change addresses issues
caused by `compileSummary` being `undefined` due to potential startup
failures of the Arduino Language Server, as noted in
https://github.com/dankeboy36/esp-exception-decoder/issues/28#issuecomment-2681800772.
The `compile` command now resolves with a `CompileSummary` rather than
`void`, facilitating a more reliable way for extensions to access
necessary data. Furthermore, the command has been adjusted to allow
resolution with `undefined` when the compiled data is partial.
By transitioning to direct usage of the resolved compile value for
state updates, the reliance on executed commands for extensions is
eliminated. This update also moves the VSIX command execution to the
frontend without altering existing IDE behavior.
Closesarduino/arduino-ide#2642
Signed-off-by: dankeboy36 <dankeboy36@gmail.com>
* fix: install missing libx11-dev and libxkbfile-dev
Signed-off-by: dankeboy36 <dankeboy36@gmail.com>
* fix: pick better GH step name
Signed-off-by: dankeboy36 <dankeboy36@gmail.com>
* fix: install the required dependencies on Linux
Signed-off-by: dankeboy36 <dankeboy36@gmail.com>
* fix(revert): do not manually install deps on Linux
Signed-off-by: dankeboy36 <dankeboy36@gmail.com>
* chore: pin `ubuntu-22.04` for linux actions
* fix: restore accidentally removed dispose on finally
Signed-off-by: dankeboy36 <dankeboy36@gmail.com>
* fix(test): align mock naming 💄
Signed-off-by: dankeboy36 <dankeboy36@gmail.com>
* fix: let the ino contribution notify the LS
+ event emitter dispatches the new state.
Signed-off-by: dankeboy36 <dankeboy36@gmail.com>
* fix(test): emit the new compiler summary state
Signed-off-by: dankeboy36 <dankeboy36@gmail.com>
* chore(revert): unpin linux version, use latest
revert of b11bde1c47
Signed-off-by: dankeboy36 <dankeboy36@gmail.com>
---------
Signed-off-by: dankeboy36 <dankeboy36@gmail.com>
Co-authored-by: Giacomo Cusinato <7659518+giacomocusinato@users.noreply.github.com>
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.
Install `libx11-dev`, `libxkbfile-dev`, `libsecret-1-dev` libraries as the most recent update to ubuntu-latest does not include them
Signed-off-by: dankeboy36 <dankeboy36@gmail.com>
Background
==========
Shared Library Dependencies
---------------------------
The Linux build of Arduino IDE has dynamic linkage against the libstdc++ and glibc shared libraries. This results in
it having a dependency on the version of the libraries that happens to be present in the environment it is built in.
Although newer versions of the shared libraries are compatible with executables linked against an older version, the
reverse is not true. This means that building Arduino IDE on a Linux machine with a recent distro version installed
causes the IDE to error on startup for users who have a distro with older versions of the dependencies.
For example, if Arduino IDE were built on a machine with version 3.4.33 of libstdc++, then attempting to run it on a
machine with an older version of libstdc++ would fail with an error like:
```
Error: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.33' not found (required by /home/foo/arduino-ide/resources/app/lib/backend/native/nsfw.node)
```
Likewise, if Arduino IDE were built on a machine with version 2.39 of glibc, then attempting to run it on a machine
with an older version of glibc would fail with an error like:
```
Error: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.39' not found (required by /home/foo/arduino-ide/resources/app/node_modules/nsfw/build/Release/nsfw.node)
```
Build Machine Requirements
--------------------------
The IDE builds distributed by Arduino should be compatible with a reasonable range of Linux distribution versions. In
order to achieve this, the builds must be performed in a machine with an older version of the shared libraries. The
shared libraries are part of the Linux distro, and installing a different version is not feasible. So this imposes a
maximum limit on the build machine's distro version.
The distributed builds are generated via a GitHub Actions workflow. The most simple approach is to run the build in the
machine of the GitHub-hosted runners provided for each operating system. However, GitHub provides a limited range of
operating system versions in their runners, and removes the older versions as newer versions are added. This means that
building in the GitHub-hosted runner machine would not allow for the desired range of Linux distro version
compatibility. For this reason, the Linux build is performed in a Docker container that provides an older version of
Ubuntu.
The same situation of incompatibility with Linux distro versions that have a version of the shared library dependencies
older than the version present on the build machine occurs for several of the tools and frameworks used by the build
process (e.g., Node.js, Python). In this case, the tables are turned as we are now the user rather than the distributor
and so are at the mercy of the Linux distro version compatibility range provided by the distributor. So this imposes a
minimum limit on the build machine's distro version.
Although several of the dependencies used by the standard build system have dependencies on versions of glibc higher
than the version 2.27 present in Ubuntu 18.04, it was possible to use this distro version in the Linux build container
by using alternative distributions and/or versions of these dependencies.
Workflow Artifacts
------------------
The build workflow uses GitHub actions workflow artifacts to transfer the files generated by the build job to subsequent
jobs in the workflow. The "actions/upload-artifact" action is used for this purpose.
Problem
=======
GitHub is dropping support for the workflow artifacts produced by the version 3.x of the "actions/upload-artifact"
action that was previously used by the build job. So the action version used in the build workflow was updated to the
current version 4.x. This version of the action uses a newer version of the Node.js runtime (20). Unfortunately the the
Node.js 20 runtime used by the action has a dependency on glibc version 2.28, which causes the Linux build job to fail
after the update of the "actions/upload-artifact" action:
```
Run actions/upload-artifact@v4
/__e/node20/bin/node: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /__e/node20/bin/node)
```
Unlike the other dependencies of the build process, it is no longer possible to work around this incompatibility by
continuing to use the older compatible version of the "actions/upload-artifact" action. It is also impossible to replace
the incompatible Node.js 20.x distribution used by the action, since it comes from the read-only file system of the
runner image. Likewise, it is not possible to configure or force the action to use a Node.js installation at a different
path on the runner machine.
Resolution
==========
Compatibility with the new version of the "actions/upload-artifact" action is attained by updating the version of Linux
in the build container to 18.10, which is the oldest version that has glibc 2.28. The presence of a newer glibc version
in the container also makes it compatible with several other dependencies of the build process, meaning the code in the
Dockerfile and workflow for working around the incompatibilities of Ubuntu 18.04 can be removed.
Consequences
============
Unfortunately this means the loss of compatibility of the Linux Arduino IDE builds with distros that use glibc 2.27
(e.g., Ubuntu 18.04). User of those distros will now find that Arduino IDE fails to start with an error like:
```
Error: node-loader:
Error: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /home/foo/arduino-ide/resources/app/lib/backend/native/pty.node)
at 85467 (/home/foo/arduino-ide/resources/app/lib/backend/main.js:2:2766)
at __webpack_require__ (/home/foo/arduino-ide/resources/app/lib/backend/main.js:2:6663105)
at 23571 (/home/foo/arduino-ide/resources/app/lib/backend/main.js:2:3374073)
at __webpack_require__ (/home/foo/arduino-ide/resources/app/lib/backend/main.js:2:6663105)
at 55444 (/home/foo/arduino-ide/resources/app/lib/backend/main.js:2:3369761)
at __webpack_require__ (/home/foo/arduino-ide/resources/app/lib/backend/main.js:2:6663105)
at 24290 (/home/foo/arduino-ide/resources/app/lib/backend/main.js:2:1780542)
at __webpack_require__ (/home/foo/arduino-ide/resources/app/lib/backend/main.js:2:6663105)
at 43416 (/home/foo/arduino-ide/resources/app/lib/backend/main.js:2:1770138)
at __webpack_require__ (/home/foo/arduino-ide/resources/app/lib/backend/main.js:2:6663105)
```
The build workflow produces binaries for a range of target hosts. This is done by using a job matrix in the GitHub
Actions workflow that produces each build in a parallel job. GitHub Actions workflow artifacts are used to transfer the
generated files between sequential jobs in the workflow. The "actions/upload-artifact" action is used for this purpose.
Previously, a single artifact was used for this purpose, with each of the parallel jobs uploading its own generated
files to that artifact. However, support for uploading multiple times to a single artifact was dropped in version 4.0.0
of the "actions/upload-artifact" action. So it is now necessary to use a dedicated artifact for each of the builds.
These can be downloaded in aggregate by using the artifact name globbing and merging features which were introduced in
version 4.1.0 of the "actions/download-artifact" action.
The "Sync Labels" GitHub Actions workflow is configured to allow the use of multiple shared label configuration files.
This is done by using a job matrix in the GitHub Actions workflow to download each of the files from the source
repository in a parallel GitHub Actions workflow job. A GitHub Actions workflow artifact was used to transfer the
generated files between sequential jobs in the workflow. The "actions/upload-artifact" and "actions/download-artifact"
actions are used for this purpose.
Previously, a single artifact was used for the transfer of all the shared label configuration files, with each of the
parallel jobs uploading its own generated files to that artifact. However, support for uploading multiple times to a
single artifact was dropped in version 4.0.0 of the "actions/upload-artifact" action. So it is now necessary to use a
dedicated artifact for each of the builds. These can be downloaded in aggregate by using the artifact name globbing and
merging features which were introduced in version 4.1.0 of the "actions/download-artifact" action.
- Use the CLI release proto.zip to get proto files for production versions of CLI
- Extract the proto files from repo if CLI version is declared as `commitsh` or version is 1.1.0
See https://github.com/arduino/arduino-cli/pull/2761
Adds a new preference to control whether the
verify command should automatically run before the
upload. If the `arduino.upload.autoVerify` setting
value is `false`, IDE does not recompile the
sketch code before uploading it to the board.
Signed-off-by: dankeboy36 <dankeboy36@gmail.com>
* fix: use `Status` enum for status code in `ServiceError` type guards
This change resolves the issue where the intersection of `ServiceError` error codes of type `number` resulted in the `never` type due to conflict between number and `State` enum if `StatusObject`
* feat: add `isInvalidArgument` type guard to `ServiceError`
* fix: retry compilation if grpc client needs to be reinitialized
See https://github.com/arduino/arduino-ide/issues/2547
It is considered good practice to use JavaScript's type-safe strict equality operator === instead of the equality
operator ==. Compliance with this practice is enforced by the project's ESLint configuration, via the "eqeqeq" rule.
The script used to generate the changelog for Arduino IDE's auto-update dialog contained an inappropriate usage of the
equality operator. This caused linting runs to fail:
arduino-ide-extension/scripts/compose-changelog.js
37:19 error Expected '===' and instead saw '==' eqeqeq
The `lint` script of the "arduino-ide-extension" package is intended to use the ESLint linter tool to check for problems
in all the package's JavaScript and TypeScript code files. It is used by the continuous integration system to validate
contributions.
Previously, the command invoked `eslint` without any arguments. With the 8.x version of ESLint used by the project, it
is necessary to provide a path argument in order to cause it to lint the contents of files. Because that argument was
not provided, the script didn't do anything at all and so would return a 0 exit status even if the code had linting rule
violations.
This is fixed by adding a `.` path argument to the command invoked by the script. This will cause ESLint to recurse
through the `arduino-ide-extension` folder and lint the code in all relevant files.
The "build" workflow builds the application for all supported targets, generates workflow artifacts from which the
builds can be downloaded by users and beta testers, and publishes nightly and production releases.
As if that wasn't enough, the workflow was also configured to check the sync of the Yarn lockfile.
This monolithic approach is harmful for multiple reasons:
* Makes it difficult to interpret a failed workflow run
* Makes the build workflow more difficult to maintain
* Increases the turnaround time for contributors and maintainers to get feedback from the CI system
The sync check operation is hereby moved to a dedicated workflow, consistent with standard practices for Arduino Tooling
projects.
The "build" workflow builds the application for all supported targets, generates workflow artifacts from which the
builds can be downloaded by users and beta testers, and publishes nightly and production releases.
As if that wasn't enough, the workflow was also configured to perform the unrelated operation of running the project's
test suites.
This monolithic approach is harmful for multiple reasons:
* Makes it difficult to interpret a failed workflow run
* Unnecessarily adds a significant amount of extra content to the already extensive logs produced by the build process
* Makes the build workflow more difficult to maintain
* Increases the length of a build workflow run
* Increases the impact of a spurious failure
* Increases the turnaround time for contributors and maintainers to get feedback from the CI system
The test run operation is hereby moved to a dedicated workflow, consistent with standard practices for Arduino Tooling
projects.
The "build" workflow builds the application for all supported targets, generates workflow artifacts from which the
builds can be downloaded by users and beta testers, and publishes nightly and production releases.
As if that wasn't enough, the workflow was also configured to perform the unrelated operation of linting the project's
TypeScript and JavaScript code.
This monolithic approach is harmful for multiple reasons:
* Makes it difficult to interpret a failed workflow run
* Unnecessarily adds a significant amount of extra content to the already extensive logs produced by the build process
* Makes the build workflow more difficult to maintain
* Increases the length of a build workflow run
* Increases the impact of a spurious failure
* Increases the turnaround time for contributors and maintainers to get feedback from the CI system
The linting operation is hereby moved to a dedicated workflow, consistent with standard practices for Arduino Tooling
projects.
The "build" workflow signs the macOS and Windows builds of the application. The signing process relies on access to GitHub Actions
secrets. For this reason, the workflow is configured to only sign the builds when it has access to GitHub Actions
secrets to avoid spurious failures of the workflow that would otherwise be caused by signing failure.
A flexible general purpose system for determining whether to attempt signing of a build was established years ago. However, a redundant system was added specific to the Windows build instead of using the existing system.
The redundant system is hereby removed. This makes the workflow easier to understand and maintain.
The "build" workflow signs the Windows builds of the application. The signing process relies on access to GitHub Actions
secrets. For this reason, the workflow is configured to only sign the builds when it has access to GitHub Actions
secrets to avoid spurious failures of the workflow that would otherwise be caused by signing failure.
Previously the signing was determined based on the value of the `github.event.pull_request.head.repo.fork` context item.
That was effective for the use case of the workflow being triggered by a pull request from a fork (for security reasons,
GitHub Actions does not give access to secrets under these conditions).
However, there is another context under which the workflow might run without access to the signing secrets, for which
the use of context item is not appropriate. 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 previous configuration would cause a workflow run performed by a contributor in a fork to attempt to sign the
Windows build. Unless the contributor had set up the ridiculously complex infrastructure required to perform the signing
for the Windows build, which is utterly infeasible, this would cause the workflow to fail spuriously.
The appropriate approach, which has been the established convention in the rest of the workflow code, is to use the
secret itself when determining whether to attempt the signing process. If the secret is not defined (resulting in it
having an empty string value), then the signing should be skipped. If it is defined, then the signing should be
performed.
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>
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.
To fix all security vulnerabilities detected by `Dependabot`.
- remove `shelljs`. replace with `fs` and `console`.
- remove `uuid`. replace with `@phosphor/coreutils`.
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
Background
----------
The Linux build of Arduino IDE is dynamically linked against the libstdc++ and glibc shared libraries. This results in
it having a dependency on the version of the libraries that happens to be present in the environment it is built in.
Although newer versions of the shared libraries are compatible with executables linked against an older version, the
reverse is not true. This means that building Arduino IDE on a Linux machine with a recent distro version installed
causes the IDE to error on startup for users who have a distro with older versions of the dependencies. For example:
```
Error: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /home/per/Downloads/arduino-ide_nightly-20231006_Linux_64bit/resources/app/lib/backend/native/nsfw.node)
```
or:
```
Error: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /home/per/Downloads/arduino-ide_2.0.5-snapshot-90b1f67_Linux_64bit/resources/app/node_modules/nsfw/build/Release/nsfw.node)
```
We were originally able to achieve our targeted range of Linux distro compatibility by running the Linux build in the
ubuntu-18.04 GitHub Actions hosted runner machine. Unfortunately GitHub stopped offering that runner machine. This meant
we were forced to update to using the ubuntu-20.04 runner machine instead, which caused the loss of compatibility of
the automatically generated builds with previously supported distro versions (e.g., Ubuntu 18.04). Since that time, the
release builds have been produced manually, which is inefficient and prone to human error.
Update
------
The identified solution to restoring fully automated builds with the target range of Linux distro compatibility is to
run the build in a Docker container that provides the suitable environment. This means a combination of an older distro
version with the modern versions of the development tool dependencies of the build.
Such a combination was achieved by creating a bespoke image based on the ubuntu:18.04 image. The Dockerfile is hosted in
the Arduino IDE repository in order to allow it to be maintained in parallel with the code and infrastructure.
Image Publishing
----------------
A "Push Container Images" GitHub Actions continuous delivery workflow is added to push updated images to the GitHub
Container registry when a commit that modifies relevant files is pushed to the main branch.
This means the image does not have formally versioned tags and the IDE build uses the container that results from the
configuration at the tip of the main branch at the time of the build. I think that is a reasonable approach in this use
case where the image is targeted to a single application rather than intended to be used by multiple projects.
Container Validation
--------------------
The build workflow is configured to trigger on completion of that push workflow in order to provide validation of the IDE build using the
updated container as well as the resulting tester builds of the IDE.
A "Check Containers" GitHub Actions continuous integration workflow is added to provide basic validation for changes to
the Dockerfile. It will automatically build the image and run the container on any push or pull request that modifies
relevant files.
Container Workflow Design
-------------------------
With the goal of reusability, the image data is contained in a job matrix in the workflow to allow them to accommodate
any number of arbitrary images.
Build Workflow Configuration
----------------------------
A container property is added to the build job matrix data. If the container.image property is set to null, GitHub
Actions will run the job directly in the runner environment instead of in a container. This allows us to produce the
builds using either a container or a bare runner machine as is appropriate for each target.
Unfortunately the latest v4 version of the actions/checkout action used to checkout the repository into the job
environment 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/checkout@v3 for the Linux build job. We will likely receive pull requests from
Dependabot offering to update this outdated action dependency for the v4 and 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.
- fix(test): integration tests are more resilient.
- run the Create integration tests with other slow tests,
- queued `PUT`/`DELETE` requests to make the test timeout happy,
- reduced the `/sketches/search` offset to 1/5th and
- remove Create API logging.
- fix(linter): ignore `lib` folder. Remove obsolete `.node_modules`
pattern.
- feat(ci): enable Create API integration tests.
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
Co-authored-by: per1234 <accounts@perglass.com>
The "Arduino IDE" GitHub Actions workflow uploads the nightly and release builds to Amazon S3, from which they are
downloaded by the auto-update as well as directly by users via the links on the "Software" page of arduino.cc.
The workflow can also be useful in forks. Either by those who want to test contributions staged in their fork prior to
submitting a PR to the parent repo, or by those maintaining a hard fork of the project. Even though these forks wouldn't
(and couldn't due to lack of access to the encrypted credential secrets only available to the workflow when ran in a
trusted context in Arduino's repo)credentials stored in Arduino's repo) use the S3 upload component of the workflow,
they may still find it valuable for continuous integration as well as continuous deployment via the tester builds and
release builds the workflow also publishes to the GitHub repository it runs in. For this reason, the workflow contains
code to determine whether it should attempt the S3 uploads.
Previously the repository name was used as the criteria in that code. The project specificity of that approach makes the
workflow less easily reusable. A more generally applicable criterion is whether the encrypted credential certificate is
defined.
The new criterion allows the workflow to be used in any repository where the administrator has created an encrypted
secret containing their AWS credentials. That might be other projects owned by Arduino, or even 3rd party projects where
the owners want to take a similar build publishing approach using their own AWS account.
The "Arduino IDE" GitHub Actions workflow uploads the nightly and release builds to Amazon S3, from which they are
downloaded by the auto-update as well as directly by users via the links on the "Software" page of arduino.cc.
The workflow can also be useful in forks. Either by those who want to test contributions staged in their fork prior to
submitting a PR to the parent repo, or by those maintaining a hard fork of the project. Even though these forks wouldn't
(and couldn't due to lack of access to the encrypted credential secrets only available to the workflow when ran in a
trusted context in Arduino's repo)credentials stored in Arduino's repo) use the S3 upload component of the workflow,
they may still find it valuable for continuous integration as well as continuous deployment via the tester builds and
release builds the workflow also publishes to the GitHub repository it runs in. For this reason, the workflow contains
code to determine whether it should attempt the S3 uploads. Previously that code was duplicated in both the nightly and
release publishing jobs of the workflow. Since the workflow already contains a job specifically for the purpose of
determining the characteristics of the build being performed and making that information available from single source
for use throughout the rest of the workflow, it makes sense to also move the S3 upload determination code to that job.
On every release tag, and manual trigger when the "Include builds on non-free runners" checkbox is checked, make the
Arduino IDE build for native Apple Silicon host in addition to the builds that are always generated by the "Arduino IDE"
GitHub Actions workflow.
Previously, the build workflow only produced a build for x86-64 (AKA "Intel") macOS hosts. Although it is possible to
use those builds on Apple Silicon machines via the Rosetta 2 translation software, the performance is significantly
inferior to a native build so we must also provide Apple Silicon native builds.
Previously the Apple Silicon builds were produced manually. The reason for using that inefficient and error-prone
approach instead of the automated continuous deployment system used for other builds was that GitHub did not provide the
necessary Apple Silicon runner machines and Arduino was not capable of setting up such self-hosted machines in a manner
that would make them feasible for the project maintainers to use. GitHub hosted Apple Silicon runner machines are now
available so we can add the target to the build workflow.
GitHub gives unlimited use of the basic runner machines for workflow runs in public repositories. However, the macOS ARM
architecture is only provided in runner machines which are classified as "larger runner". Use of these runners is
charged on a per-minute basis, without any of the free allowances GitHub provides for the normal runners. In order to
avoid unnecessary expenditures, native Apple Silicon builds must be generated only when there is compelling reason to do
so. Such a build is needed for every release, so the workflow is configured to always generate the builds when triggered
by a tag. In addition to releases, Apple Silicon tester builds for pull requests that might have special implications
for this target. For this reason, the workflow is configured to allow Apple Silicon builds to be triggered manually by a
repository maintainer.
The workflow uses a job matrix to run the build for each target on the appropriate runner machine in parallel, using the
universally applicable workflow code for all jobs. It uses another job matrix to generate individual workflow artifacts
for the tester builds of each target. Previously it was possible to always use the same matrix configurations for all
workflow runs. With the addition of the selectively run macOS ARM job, it is now necessary to generate these matrixes on
the fly.
The electron-updater package used by Arduino IDE's auto-update capability uses a data file (known as the "channel update
info file") to check for the availability of updates. A single "channel update info file" is used for the data of the
macOS x86 and ARM builds. Since a separate job is used to produce each of those builds, this means the "channel update
info file" produced by each of the macOS build jobs must be merged into a single file.
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 contains code that
uses various criteria to determine the build type.
Previously that code was duplicated in multiple places:
- The packaging job
- The changelog generation job
- The nightly build publishing job
- The release publishing job
This duplication is avoided by moving the code to a dedicated job that makes the build type information available to all
subsequent jobs via outputs.
The "Arduino IDE" GitHub Actions workflow uses a job matrix to make the builds for each host target in parallel.
The same steps are used for each job, but some configuration adjustments must be made on a per-target basis. This is
done through various attributes in the matrix configuration.
Previously the `os` attribute was used for two distinct things:
- The machine identifier of the GitHub Actions runner machine of the job.
- The differentiator in the human-targeted job name.
The attribute name "os" (for "operating system") was misleading because runners are differentiated by more than only the
operating system on the machine.
The use of a machine identifier as a differentiator in the human-targeted job name was a bad idea because these
identifiers would only effectively communicate the nature of a build to humans who are quite knowledgeable about the
GitHub Actions workflow syntax.
The impact of these poor decisions has not been too severe previously due to there only being a single job for each
operating system. However, there is a need for multiple jobs per operating system in order to support multiple host
architectures (e.g., macOS x86 and ARM).
The solution is to:
- Use an appropriate name for the runner identifier attribute.
- Use a dedicated attribute for the human friendly job name differentiator.
- update status bar if board+port is restored,
- refresh the debug toolbar if board+port is restored,
- init `Include Library` if board+port is ready, and
- init library examples if board+port is ready
Closes#2237Closes#2239
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
Store the board config data per sketch and not per IDE installation.
The (Theia) default `StorageService` implementation is workspace-scoped
when `@theia/workspace` is part of the final application.
Closes#2240
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
- Update to `electron-builder@24.6.3`.
- Fix obsolete electron security section in the development docs.
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
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>
- 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: cff2c95684Closes#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>
supported when the monitor widget was the current in the bottom panel,
and the core command (upload/verify/etc./) was successful
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
to avoid duplicate editor tabs when opening a sketch with no previously
saved workbench layout
Closes#1791
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
so when starting the debugger the CLI config path is used by the CLI for
the `daemon -I` command.
Closes#1911
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
The Arduino Sketch Specification defines the allowed format of sketch folder names and sketch code filenames. Arduino
IDE enforces compliance with the specification in order to ensure sketches created with Arduino IDE can be used with any
other Arduino development tool.
The Arduino Sketch Specification has been changed to allow a leading underscore in sketch folder names and sketch code
filenames so IDE's sketch name validation must be updated accordingly.
`Can't write debug log: available only in text format` error is thrown
by the CLI if the `--debug` flag is present.
Ref: arduino/arduino-cli#2003
Closes#1942
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
The Arduino IDE release includes several tool dependencies. Unstable versions of these tools may be pinned provisionally
for use with the development version of Arduino IDE, but production releases of Arduino IDE must use production releases
of the tool dependencies.
The release manager should check the tool versions before making a release, but previously this step was not mentioned
in the release procedure documentation.
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.
The Arduino IDE update check uses a "channel update info file" on Arduino's download server. This file specifies the
latest version of Arduino IDE available from the Arduino download server as well as the download URLs for the release
archives.
There is a separate channel file for each host operating system:
- Windows
- Linux
- macOS
Two macOS host architectures are now supported:
- x86 (AKA "Intel")
- ARM64 (AKA "Apple Silicon")
These each have their own release archive files. The macOS channel file contains data on both. So the updater must be
able to identify the appropriate archive to use for the update based on the host architecture. This is based on the
archive filename.
Arduino IDE's auto-update feature is built on the electron-updater package. The release archive selection is handled by
the electron-updater codebase and the filename pattern is hardcoded there. It selects the archive file that contains
`arm64` in its name (case sensitive), if present, to use for updates on macOS hosts with ARM64 architecture.
Previously, the build system produced archive files with the name format arduino-ide_<version>_macOS_ARM64.zip,
consistent with the established naming in other Arduino tooling projects. Unfortunately this naming would cause either
(depending on the order of the entries in the channel file) the x86 build to be used to update ARM64 macOS hosts
(resulting in lesser performance due to Rosetta 2 overhead) or the ARM64 build to be used to update x86 hosts (resulting
in the IDE failing to start).
So it is necessary to change the build artifact name to follow the format dictated by the electron-updater package.
Although it is not required (because electron-updater uses separate channel files for the x86 and ARM hosts), the Linux
archive filename format was also changed for the sake of consistency.
IDE2 needs a way to manually sign the application on M1.
The 'MACOS_FORCE_NOTARIZE' env variable forces the
notarization to proceed if not on a CI.
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
Arduino IDE's "Edit > Copy for Forum (Markdown)" feature copies the contents of the currently selected editor tab to the
clipboard, with "fenced code block" markup added to provide correct formatting when the content is posted to a platform
supporting Markdown language such as Arduino Forum, GitHub, Stack Exchange, etc.
One of the most common points of friction between the volunteer helpers on the forum and the newcomers requesting
assistance is the failure to use the correct markup when posting code. In the best case scenario the code and thread is
made less readable and less convenient to copy to the IDE for further investigation. Components of the code often
resemble markup, which causes it to be corrupted by the forum's renderer.
Even in cases where the user was conscientious enough to attempt to add the right markup, which is facilitated by tools
such as "Copy for Forum (Markdown)", they often still don't get it quite right. So it is worthwhile to make efforts to
make it less likely for the markup to be inadvertently invalidated.
"Fenced code block" markup must be on its own lines before and after the code content. Someone not familiar with
Markdown won't know this fact and may simply paste the content copied via "Copy for Forum (Markdown)" without manually
adding a newline before and after. Since the code content is preceded and succeeded by a newline, they will not have any
visual indication of a problem.
Adding a newline before and after the content will ensure the markup is valid regardless of the context it is pasted
into. In cases where the user did add a newline and this introduces a redundant line break in the forum post, it will
not have any effect on the rendered content because the additional newlines are ignored by the renderer.
- The gRPC core client provider requires an initialized config service when processing the error message received during the `InitRequest`
- Additional logging in the config service.
- The tests log into the console.
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
- code files will be copied to sketch folder root
- other files go under the `data` folder in the sketch folder root
Closes#284
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
When the widget is opened the first time with any search options,
the widget might miss the refresh event as it does not happen at
instantiation time. This PR ensures that all list widget refresh
events wait until the React component is rendered and is visible
in the UI.
This change also ensures that the debounced search will run with
the most recent search options by setting the `trailing` property
of the debounced function to `true`.
Closes#1740
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
The "Check Certificates" GitHub Actions workflow uses OpenSSL to check for problems with the project's signing
certificates.
Certificates exported to PKS#12 archive files using older tools may have been encrypted using the "RC2-40-CBC"
algorithm.
Due to the availability of more secure modern alternatives, default support for RC2-40-CBC encryption was dropped in
OpenSSL 3.x.
The macOS signing certificate uses this RC2-40-CBC encryption.
The "Check Certificates" GitHub Actions workflow runs on the `ubuntu-latest` runner. Previously, this runner used Ubuntu
20.04. This has now changed to Ubuntu 22.04. With the operating system update came an OpenSSL update from 1.1.1f to
3.0.2. This caused the workflow runs to fail on the macOS certificate job:
Error outputting keys and certificates
80FBB0C5087F0000:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:../crypto/evp/evp_fetch.c:349:Global default library context, Algorithm (RC2-40-CBC : 0), Properties ()
Even though no longer done by default, OpenSSL still supports RC2-40-CBC encryption via its "legacy" provider. So
compatibility with the certificate is restored by adding the `-legacy` flag to the `openssl pkcs12` commands.
Manually update the menus when executing the command.
Also disabled the menu when the settings dialog is opened.
closes#1735
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
The "Arduino IDE" GitHub Actions workflow generates a changelog from the commits since the last tag.
This changelog is published in multiple ways:
- Printed to workflow run logs
- Uploaded to Arduino's download server (mostly useful for the nightly builds)
- Initial version of release notes
For the last, the changelog text must be passed from the dedicated changelog generation workflow step to the release
step. This is done via workflow job output.
At the time the system was set up, outputs for workflow `run` steps were set using the `set-output` workflow command.
That "workflow command" system was later determined by GitHub to have potential security vulnerabilities, so it was
replaced with a `GITHUB_OUTPUT` environment file.
The "Arduino IDE" workflow was migrated to the new "environment file" approach. It was later discovered that there was
an undocumented breaking change in the method for handling multi-line strings in workflow step outputs between the old
"workflow command" system and the new "environment file". This resulted in the initial release notes having an incorrect
format. For example, what would previously have been formatted like this:
- Updated translation files (#1606) [23c7f5f]
- Use 0.29.0 CLI in IDE2 (#1683) [f1144ef]
Was now formatted like this:
- Updated translation files (#1606) [23c7f5f]%0A - Use 0.29.0 CLI in IDE2 (#1683) [f1144ef]%0A
The solution is to remove the commands that did the escaping of the changelog text in a manner that is no longer
supported and replace them with a "here document"-style format.
A random number is used as the "delimiter" (limit string) per the security recommendations in the official GitHub
documentation. Note that even though the multiline strings handling documentation was placed under the environment
variable section, it also applies to setting outputs.
The issue forms are configured to request the contributor to test using the nightly build of Arduino IDE before
submitting an issue in order to make sure the bug or feature request has not already been resolved.
Some time ago, the repository's readme contained a table of download links. The links in the issue forms pointed there.
That table was replaced with a link to the official "Software" page in order to reduce unnecessary verbosity and
maintenance burden of the project's documentation content.
The issue form links were not updated at that time. The resulting additional link in the chain made obtaining the
nightly build less convenient for the contributor to obtain.
The links are hereby updated to point directly to the list of nightly build download links on the arduino.cc "Software"
page.
Do not try to parse the original `NotFound` error message, but look for
a sketch somewhere in the requested path.
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
From now on, the editor widget open promise resolution does not rely on
internal Theia events but solely on @phosphor's `isAttached`/`isVisible`
properties.
The editor widget promise resolves with the next task after a navigation
frame so the browser can render the widget.
Closes#1612
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
The original (`fs-extra`-based) implementation did not check if the
file is writable either.
Resources are not writable in mounted AppImages.
Closes#1586
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
- feat: generalized Node.js error handling
- Gracefully handle when the sketch folder has been deleted
- feat: spare detecting invalid sketch name error
- The invalid sketch name detection requires at least one extra FS access.
Do not try to detect the invalid sketch name error, but use the original
`NotFound` from the CLI.
- fix: typo
Closes#1596
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
GitHub Actions provides the capability for workflow authors to use the capabilities of the GitHub Actions ToolKit
package directly in the `run` keys of workflows via "workflow commands". One such command is `set-output`, which allows
data to be passed out of a workflow step as an output.
It has been determined that this command has potential to be a security risk in some applications. For this reason,
GitHub has deprecated the command and a warning of this is shown in the workflow run summary page of any workflow using
it:
The `set-output` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more
information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/
The identical capability is now provided in a safer form via the GitHub Actions "environment files" system. Migrating
the use of the deprecated workflow commands to use the `GITHUB_OUTPUT` environment file instead fixes any potential
vulnerabilities in the workflows, resolves the warnings, and avoids the eventual complete breakage of the workflows that
would result from GitHub's planned removal of the `set-output` workflow command 2023-05-31.
The "github-stats" GitHub Actions workflow periodically gathers GitHub release asset download statistics for Arduino CLI
and pushes the results to Datadog.
There are no known problems with this workflow. However, the companion "arduino-stats" workflow that did the same for
the downloads of Arduino IDE from downloads.arduino.cc was broken and thus removed from the repository.
The GitHub stats are not very valuable on their own as they only provide an unknown fraction of the total downloads of
Arduino IDE. They have also not ended up being used.
The workflow also uses deprecated Node.js 12 runtime, which currently results in warnings printed to the workflow run
summary page, but will eventually cause the complete breakage of the workflow.
Since it doesn't provide any value and represents a maintenance burden, the workflow is hereby removed from the
repository.
The "arduino-stats" GitHub Actions workflow was designed to periodically gather download statistics from Arduino CDN and
push results to Datadog.
The recorded stats from the identical system in the Arduino CLI repository showed a periodic decrease in total download
count. Since this is patently impossible, it is clear that something is wrong with the system and that the recorded data
is not trustworthy. An investigation into the problem
was never done.
On 2022-03-14, the runs of the "arduino-stats" GitHub Actions workflow began to fail. Because there had not been any
relevant change in the repository between the last successful run and the first failing run, it seems that some external
change caused the breakage.
The workflow also uses deprecated Node.js 12 runtime-based actions and set-output workflow command, which currently
results in warnings printed to the workflow run summary page, but will eventually cause the complete breakage of the
workflow.
Since the workflow was not ever working successfully and the lack of an investigation about that indicates that the
stats are not of immediate importance, the best course of action is to simply remove the broken infrastructure from the
repository rather than investing time into fixing something that isn't being used anyway.
Dependabot will periodically check the versions of all actions used in the repository's workflows. If any are found to
be outdated, it will submit a pull request to update them.
NOTE: Dependabot's PRs will occasionally propose to pin to the patch version of the action (e.g., updating
`uses: foo/bar@v1` to `uses: foo/bar@v2.3.4`). When the action author has provided a major version ref, use that instead
(e.g., `uses: foo/bar@v2`). Dependabot will automatically close its PR once the workflow has been updated.
More information:
https://docs.github.com/code-security/dependabot/working-with-dependabot/keeping-your-actions-up-to-date-with-dependabot
On every startup, the 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.
* Added a modifiable default sketch for new project
* Removed unused file
* WiP : Now nothing's working... :(
* yarn i18n:generate for the settings
* Updated the desription for markdown description.
* Lintered the code
* Remove undesirable whitespaces
* Applied kittaakos suggestions
* Removed extra whitespaces
* Fixed default `.ino` for the missings empty lines.
- The implementation has been taken from @kittaakos repo
d10de01736/arduino-ide-extension/src/browser/serial/monitor/serial-monitor-send-input.tsx
- The previous method has been modified to ensure the first element instead of an empty string is returned if the index is at the beginning of the list.
- The push method has been modified to check if the current command is same as the last command. If same then, it is not added to the list else it is added.
* let the user edit the stepper input with keyboard
* consider exceptions and fix styling
* fix onBlur with empty strings
* always set the internal state value
* misc fixes
Co-authored-by: David Simpson <45690499+davegarthsimpson@users.noreply.github.com>
It is common for a "port" to be used in some way during the process of uploading to a board. However, the array of
Arduino boards is very diverse. Some of these do not produce a port and their upload method has no need for one.
For this reason, the IDE must allow the upload process to be initiated regardless of whether a port happens to be
selected. During the addition of support for user provided fields, an unwarranted assumption was made that all boards
require a port selection for upload and this resulted in a regression that broke uploading for these boards. This
regression was especially user unfriendly in that there was no response whatsoever from the IDE when the user attempted
to initiate an upload under these conditions.
The bug is hereby fixed. The upload process will always be initiated by the IDE regardless of whether a port is
selected. In cases where a port is required, the resulting error message returned by Arduino CLI or the upload tool will
communicate the problem to the user.
If the board select dialog is listening on the backend's event,
the frontend might miss the event when it comes up, although boards
are connected and ports are discovered.
Closes#573
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
* Fix boards listing
* use arduio-cli sorting fix
* re-use code to handle board list response
* change `handleListBoards` visibility to `private`
* pad menu items order with leading zeros to fix alphanumeric order
It has been removed from the gRPC API: arduino/arduino-cli#1890
This PR switches from `real_name` to `name` in the UI, as the `name` is
the canonical form provided by the CLI.
Closes#1525
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
- IDE2 can start if the package index download fails. Closes#1084
- Split the lib and platform index update. Closes#1156
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
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.
This release updates the formatting of the examples to be compliant with the code style of the Arduino IDE 2.x
"Auto Format" feature.
Arduino libraries may specify dependencies on other libraries in their metadata. The installation of these dependencies
is offered by the Arduino IDE when the user installs the dependent library using the Library Manager widget.
The order of the buttons in the dialog that offers the dependencies installation was recently rearranged. The dialog
response interpretation code was not updated to reflect the changes to the button indexes at that time. This caused the
"CANCEL" button to trigger the behavior expected from the "INSTALL ALL" button, and vice versa.
The library dependencies installation dialog response interpretation code is hereby updated to use the new button
indexes.
An "INSTALLED" label is shown on the items in the Library Manager and Boards Manager views that are currently installed
on the user's system.
During some work to add missing internationalization to the UI strings, this text was changed to "INSTALL". That text is
not appropriate for what this label is intended to communicate.
The regression is hereby corrected, while retaining the internationalization of the string.
Arduino IDE has been translated to several languages.
The localization process follows the following steps:
1. An English language source string is defined in the Arduino IDE codebase
2. The source string is pushed to Transifex
3. Community translators localize the string
4. The localization data is pulled into the Arduino IDE repository
5. The localization data is incorporated into the Arduino IDE distribution
Experience with maintenance of Arduino's localized projects indicates that the data files generated at step (4) can
appear to be the appropriate place to make edits for casual contributors not familiar with the project's sophisticated
internationalization infrastructure.
Since those files are generated by automated systems, any edits made there would only be overwritten, so it is important
to clearly communicate the correct way to make enhancements or corrections to these strings. This is accomplished by a
local readme file most likely to be seen by those working in the folder containing these files, which supplements the
existing information about translation in the project's translation guide.
Translation of the strings of the Arduino IDE UI is a valuable contribution which helps to make Arduino accessible to
everyone around the world.
Localization of the Arduino-specific strings of the IDE is done in the "Arduino IDE 2.0" project on Transifex.
Previously, the "Translation" row in the contribution methods summary table in the contributor guide entry page simply
linked to that project.
Arduino IDE also uses localized strings from several other sources:
- VS Code language packs
- Arduino CLI
Users may notice unlocalized strings or errors or areas for improvement in the existing translations and wish to
contribute translations. For this reason, it is important to also provide instructions for contributing to those other
localization data sources. The contribution methods summary table can not effectively accommodate that additional
content so a dedicated document is added for the purpose. This will also allow linking directly to that document from
related documentation or conversations.
Contributor are presented with an issue template chooser page at the start of the issue creation process.
In addition to the issue report templates, some "contact links" provide information and links to other communication
channels. In order to encourage high quality issues, a link to the "issue report guide" is included on this page.
Previously that link pointed to an incorrect URL, resulting in a 404 error for those who visited it. The URL is hereby
corrected.
On every startup, the 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
The previous release procedure caused the <version> component of these to be the version of the most recent release.
During the pre-release phase of the project development, all releases had a pre-release suffix (e.g., 2.0.0-rc9.4).
Appending the "snapshot" or "nightly" suffix to that pre-release version caused these builds to have the correct
precedence (e.g., 2.0.0-rc9.2.snapshot-20cc34c > 2.0.0-rc9.2). This situation has changed now that the project is using
production release versions (e.g., 2.0.0-nightly-20220915 < 2.0.0). This caused users of "snapshot" or "nightly" builds
to be presented with a spurious update notification on startup.
The solution is to do a minor bump of the version metadata after creating the release tag. That was not done immediately
following the 2.0.0 release. The omission is hereby corrected.
This will provide the metadata bump traditionally done before the creation of the release tag in the event the version
number of the next release is 2.0.1. 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.
On every startup, the 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
The previous release procedure caused the <version> component of these to be the version of the most recent release.
During the pre-release phase of the project development, all releases had a pre-release suffix (e.g., 2.0.0-rc9.4).
Appending the "snapshot" or "nightly" suffix to that pre-release version caused these builds to have the correct
precedence (e.g., 2.0.0-rc9.2.snapshot-20cc34c > 2.0.0-rc9.2). This situation has changed now that the project is using
production release versions (e.g., 2.0.0-nightly-20220915 < 2.0.0). This caused users of "snapshot" or "nightly" builds
to be presented with a spurious update notification on startup.
The solution is to add a step to the end of the release procedure to do a minor bump of the version metadata after
creating the release tag.
This means that the metadata bump traditionally done before the creation of the release tag will already have been done
in advance for patch releases. However, it will still need to be done for minor or major releases.
The release procedure documentation is hereby updated to produce correct tester and nightly build version precedence.
The metadata bump step is moved from before to after the tag creation step, replaced by a new step to verify the version
before the tag creation, updating it in the event it is not a patch release. Both those steps may require updating the
metadata. As an alternative to maintaining duplicate copies, each step links to a single copy of the fairly complex
instructions for doing so. The structure of the document is adjusted to accomodate this, by placing the steps of the
procedure under a "Steps" section and creating a new "Operations" section to contain any such shared content.
The release procedure is a set of steps which must be performed in a specific sequence. This fact is more effectively
communicated by formatting it as an ordered list.
Previously the instructions for updating the npm package metadata, submitting a PR for that, and merging the PR was in
the same section as the tag push instructions in the release procedure documentation.
These two operations are distinct from each other. Mashing them into a single step makes the release procedure document
difficult to read and the process more prone to error.
For this reason, a dedicated step is used for each of the two things.
* fix board selection and workspace input dialogs width and height
* use same dialog for new file and rename
* fix board list getting small when filtering
* board select dialog: show variant text when no board is found
* fix addition boards url outline
- From now on, NSFW service disposes after last reference
is removed. No more 10sec delay.
- Moved the temp workspace deletion to a startup task.
- Can set initial task for the window from electron-main.
- Removed the `browser-app`.
Closes#39
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
For security reasons, the macOS tester builds generated for PRs from forks are not notarized. Instructions are provided for
beta testing under these conditions.
Previously, the instructions for bypassing the macOS notarization requirement involved disabling macOS Gatekeeper
entirely using the spctl command. These instructions are hereby replaced by an alternative approach, where the
restriction is bypassed for the Arduino IDE application alone, via the macOS GUI.
The new approach is superior for the following reasons:
- More secure due to having limited scope
- More accessible due to the use of the macOS GUI
The readme should provide a concise overview of the essential information about the project. Additional details are
provided in dedicated documents, so the readme only needs to provide links to that information.
Documentation of how to contribute to the project gives everyone the opportunity to participate, while also reducing the
maintenance effort and increasing the quality of contributions.
This guide documents the various ways of contributing to the project.
Previously, the information about tester builds was mixed in with the documentation about building the project from
source.
The two subjects are of relevance to two distinct contribution options. Building from source will primarily be done by
developers working on the project code base. Tester builds will be used by beta testers and reviewers.
For this reason, it doesn't make sense to require beta testers to wade through a lot of development documentation not
directly related to their work in order to find the instructions for obtaining tester builds. Likewise, it doesn't make
sense to clutter up the development documentation with such information.
Moving the information about tester builds to a dedicated file makes it easier for the interested parties to find, and
also allows the creation of a comprehensive guide for beta testers without making a negative impact on the development
documentation content.
Previously, information about project development was stored in a file named BUILDING.md in the root of the repository.
That content is hereby moved to the file docs/development.md. This will provide the following benefits:
- Broaden the scope of the file to all information related to development rather than building only
- Store all documentation content under a single folder instead of randomly putting some in the root and others under
docs
The Arduino IDE has an auto update capability. A new version is checked for on every startup, and if available the user
is offered an update.
Although this update can usually be done automatically by the IDE, under some conditions this is not possible. For
example:
- The IDE package in use does not support auto update (i.e., Linux ZIP package)
- The file could not be downloaded due to a transient network service outage
In this case, the user is presented with a friendly dialog that explains the situation and links to the "Software" page
on arduino.cc, where the user can manually download and install the new version.
During the pre-release development phase of the project, the download links for Arduino IDE 2.x were on a sub-section of
the "Software" page. For this reason, the linked URL included the fragment identifier `#experimental-software` so that
the page would load scrolled down to the anchor at that section of the page.
With the 2.0.0 release, the Arduino IDE 2.x project has graduated to a production development phase. For this reason,
the download links have been moved to the top of the "Software" page and the now inaccurate `experimental-software`
anchor removed from the page.
The previous link with that fragment is still perfectly functional, but the fragment to a non-existent anchor serves no
purpose and also miscommunicates the project status to users who notice the URL that was loaded. For this reason, it is
hereby removed from the link.
During the early phase of development, the download links for the nightly build were only available from the table in the project readme.
Since that time, download links were also added to the "Software" page on arduino.cc, which is already linked to from
the readme. This means the nightly build link table is superfluous and only harms the readability of the readme.
The superfluous table is hereby removed from the readme.
An internal release procedure document was created separately from the documentation hosted in this repository. That
internal document became significantly more comprehensive and up to date than the unmaintained documentation in this
repository.
In order to avoid either the burden of maintaining two copies of the same information, or more likely the out of sync
state between the information in the two resulting from lack of such maintenance, a single document will be maintained
here in this repository.
The superior version of the information from the internal document is hereby migrated to the repository where it will be
maintained from here on.
Previously, the procedure for creating a new release of the project was included in the development documentation.
This information is distinct from the rest of the contents of that file in that it is not of any value or interest to
most contributors from the community since only project maintainers will ever create a release. This meant that it make
the document less readable and approachable without adding significant value in return.
The information is still essential to the project maintainers, so it must not be removed, but it can be moved to a
dedicated file under the existing `docs/internal/` folder that is specifically intended for storing such information.
Although the Arduino IDE's primary preferences interface provides all required configuration capabilities, advanced
users may wish to fine tune the behavior of the application or temporarily enable additional log output to use for
troubleshooting problems with the IDE.
The IDE provides such settings in a separate interface.
Previously, the existence and access procedure for these settings was undocumented.
Since this is an advanced capability, the documentation is not appropriate for inclusion with the standard user
documentation on arduino.cc. A file here in the Arduino IDE is used instead. This file will serve as a container for all
such user-targeted documentation.
- Fixed scrollbar does not reach end of list widget.
- Estimated row heights to provide better scroll UX.
- Last item's `<select>` must be visible.
Closes#1380Closes#1381Closes#1387
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
Arduino CLI is a tool dependency of Arduino IDE. For this reason, the necessary Arduino CLI build is acquired whenever
running the `yarn` command in the repository.
The way the Arduino CLI build is acquired depends on the type of version specified as dependency in the
`arduino.cli.version` field of the arduino-ide-extension package metadata:
- Release/nightly: download pre-built standard distribution
- Git ref: build from source
This means that, in the latter case, all build dependencies of Arduino CLI must be present. While the Go module
dependencies are automatically installed during the build, the build tool dependencies must be installed in advance:
- Go programming language
- Task task runner
Arduino IDE's infrastructure was recently changed to use the Task tool to build Arduino CLI in the supported manner. A
step to install Task was not added to some of the workflows that run `yarn`, which caused them to fail when a
non-release version of Arduino CLI was used as a dependency:
arduino-ide-extension: >>> Building the CLI...
arduino-ide-extension: /bin/sh: 1: task: not found
arduino-ide-extension: error Command failed with exit code 1.
A step for the missing tool dependency is hereby added to those workflows.
The lack of an explicit installation of the other dependency, Go did not result in an error because Go is pre-installed
on the GitHub Actions runner. However, the installed version may not match the version Arduino CLI is intended to be
built with and validated for, and the version provided by the runner may change at any time. For this reason, it will be
safest to explicitly set up the appropriate version of Go in the workflows.
The board search input field of the "Select Other Board and Port" dialog uses placeholder text to explain the usage of
the field to the user.
All other placeholder text in the IDE's UI uses sentence case. This specific placeholder was the exception, using
unpleasant caps lock instead.
The inconsistency is resolved by changing the placeholder text to the standard sentence case.
The text of the Arduino IDE user interface has been localized to 12 languages.
Before localization can be accomplished, internationalization must be done in the application's code base:
- Set up infrastructure to export localization data
- Pass all target strings to that infrastructure
While the first of these tasks is completed, the second was not completed for several strings which are part of the user
interface.
Those outstanding strings are hereby internationalized and will be made available for localization.
Selecting "Help > Environment" from the Arduino IDE menus opens a page containing usage information for the Arduino IDE
application in the browser.
Previously, the URL used was the same as that of in Arduino IDE 1.x:
https://www.arduino.cc/en/Guide/Environment
The documentation from that page was written for Arduino IDE 1.x. Even though the UI of the two versions is aligned for
the most part, some advancements made for the 2.x major version series resulted in some differences. This means that
documentation targeted at Arduino IDE 1.x is not always applicable to Arduino IDE 2.x.
Fortunately, documentation is now available for each major version series of the IDE. So resolution is only a matter of
pointing the menu item at the correct URL.
* make dialogs scroll when scaling up the UI
* add unit of measure to settings step input
* wrap settings dialog items when scaling up the UI
* fix dialogs width when scaling up the UI
* rework board config UI to make it scale up better
* refactor ide updater dialog: move buttons outside the dialog content
* refactor ide updater dialog: clean-up code and rename events
* fix board config dialog title case and and remove double ellipsis
The Arduino IDE's "Auto Format" feature is configured to produce the standard Arduino sketch formatting style by
default.
The Arduino IDE editor's default settings are compliant with that style. However, the user may adjust the editor
settings. In this case, the Arduino IDE automatically adjusts the Auto Format configuration to align with the user's
preferences.
The formatter configuration is consumed by several other projects in addition to the Arduino IDE. For this reason, the
configuration is hosted and maintained in a centralized location, from which it is pulled by all projects that use it.
Previously, the adjustment of the Arduino IDE formatter configuration according to the editor settings was integrated
into the configuration object itself. This meant that the standardized configuration had to be modified each time it was
pulled in to sync from the upstream source.
Moving the base formatter configuration object to a dedicated file, separated from the handling and adjustment code
allows syncs to be done by simply replacing the existing configuration file with the one automatically generated by the
CI system of the repository where the source configuration is hosted.
Arduino IDE has dependencies on the clangd C++ language server and ClangFormat code formatter tools. These are updated
periodically to benefit from the ongoing development on those projects.
The update procedure requires operations in three different repositories:
- Generate builds in arduino/clang-static-binaries
- Validate and update formatter configuration in arduino/tooling-project-assets
- Update metadata in arduino/arduino-ide
Previously, this was undocumented and the procedure existed only in the form of "institutional memory".
The procedure is now fully documented in the readme of arduino-ide-extension.
The Arduino IDE's "Auto Format" feature is configured to produce the standard Arduino sketch formatting style, as
established by the Arduino IDE 1.x formatter.
The configuration is consumed by several other projects which require the configuration in a YAML file. In order to
provide all the consumers with a single canonical source and to locate the infrastructure and activity related to the
maintenance of the file in a more appropriate repository, it is now hosted in a permanent location in the
`arduino/tooling-project-assets` repository.
The following changes have been made to the source configuration:
- Move documentation comments to a dedicated file in the upstream repository
- Make additional non-functional changes to the configuration format to facilitate maintenance
- Update to use the configuration API of ClangFormat 14.0.0
This last item did result in some functional changes to the configuration which will result in minor differences in the
formatter output.
These are actually reversions of unwanted differences from the Arduino IDE 1.x formatter output, which were unavoidable
when using the 11.0.1 version of ClangFormat in use at the time of the configuration's creation. These changes will
provide greater consistency during the migration from Arduino IDE 1.x to 2.x. The default output of the Arduino IDE
1.x formatter will continue to be considered the "gold standard" until Arduino IDE 2.x graduates from "pre-release"
status.
The Arduino IDE 2.x formatter configuration is fully customizable according to the preferences of each user. Those
already using custom configurations will not be affected in any way (though they are encouraged to sync their
configuration files from the source to bring them into compliance with the configuration API of the ClangFormat version
currently in use by Arduino IDE 2.x).
See the documentation and commit history for the source file for details on the configuration changes:
https://github.com/arduino/tooling-project-assets/tree/main/other/clang-format-configuration
The sketch code formatter configuration is passed to the ClangFormat tool as a string representing a JSON object via a
command line argument.
Previously, the contents of this string were not given any special treatment to ensure compatibility with the command
interpreter used on Windows machines. That did not result in problems only because the configuration didn't contain
problematic combinations of characters. This good fortune will not persist through updates to the configuration, so the
command must be properly processed.
The Windows command interpreter does not use the POSIX style backslash escaping. For this reason, escaped quotes in the
argument are recognized as normal quotes, meaning that the string alternates between quoted and unquoted states at
random. When a character with special significance to the Windows command interpreter happens to occur outside a quoted
section, an error results.
The solution is to use the Windows command interpreter's caret escaping on these characters. Since such an escaping
system is not recognized by POSIX shells, this is only done when the application is running on a Windows machine.
References:
- https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/echo#remarks
- https://en.wikipedia.org/wiki/Escape_character#Windows_Command_Prompt
The sketch code formatter configuration is passed to the ClangFormat tool as a string representing a JSON object via a
command line argument.
The quotes in the JSON syntax are escaped in order to make them compatible with this usage. Previously, consideration
was not given to escaping of the content. For example, with the previous escaping code, this content: `\"` would be
converted to `\\"`, whereas the correct escaping would look like `\\\"`.
That did not result in problems only because the configuration didn't contain escaped content. This good fortune will
not persist through updates to the configuration so the command must be properly processed.
The content of the configuration will now be escaped in addition to the quotes of the JSON data format.
* Update BUILDING.md
Added "Notes for Linux contributors" based on my own building experience
* Update BUILDING.md
Removing the linux specific section and instead updating the Theia IDE prerequisites link to point to the mentioned file directly.
- Debounced the connectivity status update.
- Silent the output channel for the Arduino LS.
- Delay the problem markers update with 500ms.
- Do not update the status bar on every `keypress` event.
- Debounced the tab-bar toolbar updates when typing in editor.
- Fixed electron menu contribution binding.
- Aligned the editor widget factory's API to Theia.
- Set the zoom level when the app is ready (Closes#1244)
- Fixed event listener leak (Closes#1062)
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
* use theme service on settings load
* use window.matchMedia in loadSettings
* typo fix
* Patched app config to dispatch on OS' theme.
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
Co-authored-by: Akos Kitta <a.kitta@arduino.cc>
* add patch for setting IDE startup theme based on OS theme
* Patched the default theme behavior.
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
* add custom themes in register
Co-authored-by: Akos Kitta <a.kitta@arduino.cc>
* move initialization of libs and platforms into new contribution
* use noOverwrite when install built-in libraries and platform
* catch errors when installing platforms and libraries at first start-up
* arduino-cli version 0.25.0-rc1
* refine platforms and libraries initialization in case of errors
* add trailing newline when libraries and platform installation fail
* use regex to check error if builtin library dependencies are already installed
* rename contribution
Restored monitor service creation state before a36524e:
Pass core client provider into new instances as a field.
Closes#1161
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
The "Arduino IDE" workflow performs the following operations when triggered on push and pull request events:
- Build application
- Lint code
- Run tests
- Produce tester packages
All of these operations are specific to the TypeScript/JavaScript code base and its infrastructure.
Previously, the workflow ran whenever any file in the repository was changed. This includes files that have no
relevance, meaning the operations performed by the workflow were pointless. In addition to general inefficiency, these
lengthy and sometimes spuriously failing unnecessary workflow runs might cause delay or confusion to both the
contributors and maintainers for what would otherwise be a simple process.
GitHub Actions provides the ability to configure path filters for the workflow triggers. The workflow will only run on
events that change files satisfying these path filters. This is "AND"ed with the `branches` filters, meaning the existing
restrictions on which branches produce a run remain unchanged. The `tags` filter is independent from the `paths` and
`branches` filters, meaning the added path filters don't make any change to which tag push events will trigger the
workflow.
GitHub Actions workflows may require access to privileged information in order to perform certain operations. GitHub
provides the capability for doing this via "repository secrets".
For security reasons, repository secrets are only accessible to a GitHub Actions workflow run when it is triggered by an
event from within the repository containing the secret. This means that a workflow which requires such secrets would
fail when run in a fork (unless the fork owner was able to set up their own secrets with suitable values).
In order to make the relevant components of the CI system friendly for use in forks by contributors validating their
work in preparation for submitting a PR, when the operations that require access to a secret are supplemental, those
operations should be configured to only run from branches of the parent repository.
Due to its unfortunate monolithic design, in addition to operations useful to contributors, the "Arduino IDE" workflow
contains several such supplemental operations:
- Code signing
- Publishing release artifacts to Arduino's server
Some attempt was previously made to configure the workflow to skip these operations when run in forks, but that
configuration was not done correctly. This made the workflow only usable by contributors with a deep enough
understanding of GitHub Actions to be able to make the necessary modifications provisionally every time they needed to
use the workflow.
The average contributor would not be capable or willing to do this, which might result in PRs being
submitted in a less validated state, increasing the burden on maintainers.
The specific misconfigurations:
**`build` job was conditional on the workflow running from `arduino/arduino-ide`**
The job itself can run just fine in a fork, so there is no reason to impose this restriction.
Since the time this conditional was added, some changes have been made to the GitHub Actions system which makes this
sort of configuration unnecessary:
- GitHub Actions is globally disabled in forks by default
- Workflows which contain a `schedule` trigger (as is the case with this one) are individually disabled by default,
requiring the repository owner to enable it specifically even after enabling GitHub Actions in general.
This means this workflow will never run unexpectedly in a fork. The fork owner will always have intentionally enabled it.
So this conditional can be removed completely.
**Code signing was conditional on PR being submitted from a branch of the base repo**
This would cause a spurious failure of the signing operation on PRs made within the contributor's fork when the signing
secrets were not defined.
The more appropriate condition of whether the signing secrets are defined or not is now used. The environment variable
name has been updated accordingly.
**`release` job was conditional on running from `arduino/arduino-ide`**
The GitHub release creation step of this job can run in any repository. It is only the step that uploads to Arduino's
AWS server which would only make sense to run from `arduino/arduino-ide`.
So the conditional is moved to the AWS upload step, allowing contributors to test the workflow's release operation in
their forks to validate related proposals.
Previously, there was some code duplication of the complex code signing certificate handling commands, which made the
related code more difficult to understand, maintain, and develop.
The cause of this duplication is that there is a separate certificate for each operating system, each of which is stored
in separate repository secrets, as well as a different certificate file extension for each OS. Since the secret names
and file extensions are associated with the operating system, it is most logical to define them via attributes alongside
the operating system definition in the job matrix configuration already used to generate the parallel job runs for
native build on each OS.
That done, the certificate handling commands are universal and the system can easily expand to additional host targets
(e.g., Apple M1) as time goes on.
The Arduino IDE attempts to provide some additional guidance to users based on matches against compilation error
messages.
This practice was established during a time when some significant breaking changes were made to the common APIs in order
to ease the transition.
Since that time, the practice has mostly been discontinued. The interpretations are only valid for very old code that is
unlikely to be used by the target users now. So their benefit is negligible. The patterns used are inexact, meaning that
the interpretations may be printed inappropriately, which is more and more likely as the cases where the matches would
be valid become increasingly rare. When the maintenance burden is taken into consideration, it is clear that the harm is
far more than any benefits from these. So they are removed.
Notes for specific interpretations:
> Please import the SPI library from the Sketch > Import Library menu.
> As of Arduino 0019, the Ethernet library depends on the SPI library.
> You appear to be using it or another library that depends on the SPI library.
The target error was more common prior to Arduino IDE 1.6.6 (released ~6.5 years ago), when it was necessary for the
sketch to contain `#include` directives for transitive in addition to direct library dependencies (SPI is a common
transitive dependency).
Due to the nature of the SPI library, it is not often used directly, and when it is used directly it is done by more
advanced users who are unlikely to forget the `#include` directive and would have no need for this interpretation even
if they did.
It is far more likely for the user to forget an `#include` for a popular library, yet Arduino rightly does not attempt
to maintain interpretations for those.
The "Sketch > Import Library" menu path was renamed to "Sketch > Include Library" ~7 years ago.
Arduino IDE 0019 was released ~12 years ago. We can safely assume the migration to the new Ethernet API is complete.
> The 'BYTE' keyword is no longer supported.
> As of Arduino 1.0, the 'BYTE' keyword is no longer supported.
> Please use Serial.write() instead.
Arduino IDE 1.0 was released ~10.5 years ago. We can safely assume the migration to the new Serial API is complete.
This compilation error pattern is now far more likely to occur due to incorrect usage of a completely unrelated
occurrence of the common `BYTE` name in the user's code.
> The Server class has been renamed EthernetServer.
> As of Arduino 1.0, the Server class in the Ethernet library has been renamed to EthernetServer.
> The Client class has been renamed EthernetClient.
> As of Arduino 1.0, the Client class in the Ethernet library has been renamed to EthernetClient.
> The Udp class has been renamed EthernetUdp.
> As of Arduino 1.0, the Udp class in the Ethernet library has been renamed to EthernetUdp.
Arduino IDE 1.0 was released ~10.5 years ago. We can safely assume the migration to the new Ethernet API is complete.
The compilation error patterns are in no way specific to the Ethernet library so is prone to false positives.
> Wire.send() has been renamed Wire.write().
> As of Arduino 1.0, the Wire.send() function was renamed to Wire.write() for consistency with other libraries.
> Wire.receive() has been renamed Wire.read().
> As of Arduino 1.0, the Wire.receive() function was renamed to Wire.read() for consistency with other libraries.
Arduino IDE 1.0 was released ~10.5 years ago. We can safely assume the migration to the new Wire API is complete.
Due to the nature of the Wire library, it is not often used directly, and when it is used directly it is done by more
advanced users who have less need for an interpretation of the compiler error.
> 'Mouse' not found. Does your sketch include the line '#include <Mouse.h>'?
> 'Keyboard' not found. Does your sketch include the line '#include <Keyboard.h>'?
I left these in because they are the most "recent" (added due to a breaking change made 7 years ago).
However, I also feel that these are harmful and should either be removed or changed. The problem is that there is a
false match when the user attempts to compile the Keyboard or Mouse libraries for a board which does not have native USB
support (e.g., Uno, Mega), even when their sketch does contain the `#include` directives that are recommended by the
interpretation. That cause of the compilation error matching the pattern is more common than the case where the user is
compiling old code or forgot the `#include` directive, for which the interpretation is valid.
Contributors may submit pull requests against development branches in the repository for either of the following valid
reasons:
- Propose changes to a previous proposal, either while it is still in development, or else in the case where the changes
are more complex/extensive than can be efficiently proposed via the PR review framework.
- The proposal is dependent on work from an unmerged PR.
Previously, the "Arduino IDE" GitHub Actions workflow was unnecessarily configured to only run for PRs based on the
`main` branch. This meant that validation and tester builds were not provided for the PRs based on other branches.
* 1032 failing upload flag for monitor mgr
* move upload failure fix logic to frontend
* misc corrections
* avoid starting monitor when upload is in progress
* avoid starting monitor when upload is in progress
* prevent monitor side effects on upload (WIP)
* send upload req after notifying mgr
* dispose instead of pause on upld (code not final)
* Revert "dispose instead of pause on upld (code not final)"
This reverts commit 2d5dff2a2d.
* force wait before upload (test)
* always start queued services after uplaod finishes
* test cli with monitor close delay
* clean up unnecessary await(s)
* remove unused dependency
* revert CLI to 0.23
* use master cli for testing, await in upload finish
* remove upload port from pending monitor requests
* fix startQueuedServices
* refinements queued monitors
* clean up monitor mgr state
* fix typo from prev cleanup
* avoid dupl queued monitor services
* variable name changes
* reference latest cli commit in package.json
Co-authored-by: Alberto Iannaccone <a.iannaccone@arduino.cc>
For example, `malformed custom board options` was incorrectly detected
as loading JSON index file error.
Closes#1036
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
Customized the shell layout restorer:
- If a resource is about to open in code editor and preview,
do not open the preview.
- If a resource is about to open in preview only, open a code
editor instead.
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
* backend structure WIP
* Scaffold interfaces and classes for pluggable monitors
* Implement MonitorService to handle pluggable monitor lifetime
* Rename WebSocketService to WebSocketProvider and uninjected it
* Moved some interfaces
* Changed upload settings
* Enhance MonitorManager APIs
* Fixed WebSocketChange event signature
* Add monitor proxy functions for the frontend
* Moved settings to MonitorService
* Remove several unnecessary serial monitor classes
* Changed how connection is handled on upload
* Proxied more monitor methods to frontend
* WebSocketProvider is not injectable anymore
* Add generic monitor settings storaging
* More serial classes removal
* Remove unused file
* Changed plotter contribution to use new manager proxy
* Changed MonitorWidget and children to use new monitor proxy
* Updated MonitorWidget to use new monitor proxy
* Fix backend logger bindings
* Delete unnecessary Symbol
* coreClientProvider is now set when constructing MonitorService
* Add missing binding
* Fix `MonitorManagerProxy` DI issue
* fix monitor connection
* delete duplex when connection is closed
* update arduino-cli to 0.22.0
* fix upload when monitor is open
* add MonitorSettingsProvider interface
* monitor settings provider stub
* updated pseudo code
* refactor monitor settings interfaces
* monitor service provider singleton
* add unit tests
* change MonitorService providers to injectable deps
* fix monitor settings client communication
* refactor monitor commands protocol
* use monitor settings provider properly
* add settings to monitor model
* add settings to monitor model
* reset serial monitor when port changes
* fix serial plotter opening
* refine monitor connection settings
* fix hanging web socket connections
* add serial plotter reset command
* send port to web socket clients
* monitor service wait for success serial port open
* fix reset loop
* update serial plotter version
* update arduino-cli version to 0.23.0-rc1 and regenerate grpc protocol
* remove useless plotter protocol file
* localize web socket errors
* clean-up code
* update translation file
* Fix duplicated editor tabs (#1012)
* Save dialog for closing temporary sketch and unsaved files (#893)
* Use normal `OnWillStop` event
* Align `CLOSE` command to rest of app
* Fixed FS path vs encoded URL comparision when handling stop request.
Ref: https://github.com/eclipse-theia/theia/issues/11226
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
* Fixed the translations.
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
* Fixed the translations again.
Removed `electron` from the `nls-extract`. It does not contain app code.
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
* Aligned the stop handler code to Theia.
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
Co-authored-by: Akos Kitta <a.kitta@arduino.cc>
* fix serial monitor send line ending
* refactor monitor-service poll for test/readability
* localize web socket errors
* update translation file
* Fix duplicated editor tabs (#1012)
* i18n:check rerun
* Speed up IDE startup time.
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
* override coreClientProvider in monitor-service
* cleanup merged code
Co-authored-by: Francesco Stasi <f.stasi@me.com>
Co-authored-by: Silvano Cerza <silvanocerza@gmail.com>
Co-authored-by: Mark Sujew <mark.sujew@typefox.io>
Co-authored-by: David Simpson <45690499+davegarthsimpson@users.noreply.github.com>
Co-authored-by: Akos Kitta <a.kitta@arduino.cc>
- Bumped `clangd` to `14.0.0`,
- Can use `.clang-format` from:
- current sketch folder,
- `~/.arduinoIDE/.clang-format`,
- `directories#data/.clang-format`, or
- falls back to default formatter styles.
Closes#1009Closes#566
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
* Use normal `OnWillStop` event
* Align `CLOSE` command to rest of app
* Fixed FS path vs encoded URL comparision when handling stop request.
Ref: https://github.com/eclipse-theia/theia/issues/11226
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
* Fixed the translations.
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
* Fixed the translations again.
Removed `electron` from the `nls-extract`. It does not contain app code.
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
* Aligned the stop handler code to Theia.
Signed-off-by: Akos Kitta <a.kitta@arduino.cc>
Co-authored-by: Akos Kitta <a.kitta@arduino.cc>
GitHub issue forms are used in this repository to facilitate the creation of high quality issues. These provide input
fields for each of the distinct classes of information which will be essential for the evaluation of the issues.
One of these fields is for the user's operating system. A dropdown menu is used for the selection of the high level
operating system type. Previously this only permitted the selection of a single option. A devoted contributor might have
made the effort to determine that the issue applies to multiple operating system types only to be met with the inability
to provide this information via the dedicated field.
The field also did not offer an option to indicate that the operating system was irrelevant to the issue (e.g., a
subject related to the repository assets).
Those issues are resolved by the following changes:
- Configure the field to allow multiple selections
- Add a "N/A" option to the menu
Arduino IDE is packaged for Windows in multiple formats:
- ZIP
- NSIS
- Windows Installer (AKA "MSI")
The interactive installer of the NSIS package makes it the best option for installation by users.
The other use case for the installers is deployment by a system administrator. The Windows Installer package was added
to offer an additional installer option for this specific use case.
In this use case, a "silent install" will often be required. Previously, the Windows Installer package was configured to
start the Arduino IDE after completing the installation. This behavior is likely to be problematic for the very use case
the Windows Installer package was intended for. That configuration was not intentional, but rather a result of using
whatever setting electron-builder happened to provide as a default.
The behavior of the Windows Installer package is hereby changed to not run after installation. This also aligns it with
the behavior of the NSIS package's silent installation (running the installer with the `/S` flag).
The behavior of the NSIS installer is unchanged:
- When in interactive mode: user chooses whether to start Arduino IDE
- When in silent mode: Arduino IDE does not start after installation
* add notes for Windows contributor in BUILDING.md
* rephrase notes for Windows contributor in BUILDING.md
* Update notes for Windows contributor in BUILDING.md
Co-authored-by: per1234 <accounts@perglass.com>
* move Notes for Windows contributors in Build from source section
Co-authored-by: per1234 <accounts@perglass.com>
This project provides the contributors with templates for the fundamental categories of issues:
- bug report
- feature request
This is helpful to the maintainers and developers because it establishes a standardized framework for the issues and
encourages the contributors to provide the essential information.
GitHub's original issue template system is very crude, simply pre-populating the issue description field with the text
from the template file.
https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository#creating-issue-templates
The contributor may be confused by being presented with a mass of Markdown and placeholder
content where they expected a field to write their issue. They also may find it inconvenient to manuever around the
framework content and replace the placeholder content.
A far better system is now available with GitHub's recently introduced form-based issue templates:
https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository#creating-issue-forms
The user is now presented with a web form. These may include multi-line input fields that have the same formatting and
attachment capabilities as the standard GitHub Issue composer, but also additional elements such as menus and checkboxes.
The use of this form-based system should provide a much better experience for the contributors and also result in higher
quality issues.
The automatically created issue template chooser provides a menu of links to the available issue report templates as
well as the security policy at the start of the issue creation process.
It is also possible to add additional arbitrary items to the chooser, through GitHub's "Contact Links" feature. These
are defined in a configuration file:
https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository#configuring-the-template-chooser
These links offer the possibility to redirect support requests and other sub-optimal usages of the issues to the
appropriate location. This benefits the user by providing them with a fast and frictionless path to what they need, and
benefits the maintainers by preventing inappropriate issues.
When using the interactive installer, the user is presented with a dialog requested they agree to this.
The previous statement about initiation of a download constituting agreement is relevant in the context of the text's source on the arduino.cc downloads page, but not at all in the context of the installer dialog.
Linux x86-64 builds of the Arduino IDE are now available in AppImage format in additional to the ZIP format.
Since only the AppImage format IDE supports auto-updates (the IDE installed from the ZIP will notify of available updates, but can't auto-update), this will be the preferred format and so good beta testing coverage of it is especially important.
The "Compose full changelog" GitHub Actions workflow generates a changelog file from the release notes and uploads this
to Arduino's server for display to the user by the IDE updater.
Previously, this workflow could be triggered by either of two events:
- Release creation
- Release edit
To reduce the possibility of endless recursion, GitHub Actions ignores events which are triggered using the
auto-generated `GITHUB_TOKEN` access token. All release creations are done automatically by the "Arduino IDE" GitHub
Actions workflow, which uses this token.
For this reason, the release creation trigger will never be used. Since the behavior of the event being ignored by
GitHub Actions under these conditions is not at all obvious, having the workflow configured for such an irrelevant
trigger can cause confusion.
The workflow will be triggered by the manual edit which is done on every release to format the raw release notes
auto-generated from the commit history. So the fact that the release creation trigger doesn't work is not a problem.
* IDE updater assorted bugfix
- add linux AppImage target
- fix hardcoded if condition that causes to always show the update dialog
- fix redundant test build version
- recalculate sha512 after notarization on macOS
* boost notarization speed
* recalculate artifacts hash
* Remove check for updates on startup setting
* Remove useless exported function
* Update template-package.json used to package IDE
* Add function to get channel file during packaging step
* Add updates check
* move ide updater on backend
* configure updater options
* add auto update preferences
* TMP check updates on start and download
* index on check-update-startup: fcb8f6e TMP check updates on start and download
* set version to skip on local storage
* add IDE setting to toggle update check on start-up
* comment out check for updates on startup and auto update settings
* Update Theia to 1.22.1
* updated CI
* download changelog and show it in IDE updater dialog
* remove useless file
* remove useless code
* add i18n to updater dialog
* fix i18n
* refactor UpdateInfo typing
* add macos zip to artifacts
* Simply use `--ignore-engines`
* Use correct --ignore-engines
* Fix semver#valid call
* Use C++17
* updated documentation
* add update channel preference
* update updater url
* updated documentation
* Fix the C++ version
* Build flag for cpp
* add disclaimer with correct node version
* Update `electron-builder`
* Fix `Electron.Menu` issue
* Skip electron rebuild
* Rebuild native dependencies beforehand
* Use resolutions section
* Update template-package.json as well
* move ide-updater to electron application
* refactor ide-updater service
* update yarn.lock
* update i18n
* Revert "Add gRPC user agent (#834)"
This reverts commit 5ab3a747a6.
* fix ide download url
* update latest file in CI
* fix i18n check
Co-authored-by: Silvano Cerza <silvanocerza@gmail.com>
Co-authored-by: Francesco Stasi <f.stasi@me.com>
Co-authored-by: Mark Sujew <msujew@yahoo.de>
An extra brace was inadvertently introduced into a template literal used to format output text in the event of an error
during compilation. This caused the text to end in a pointless `}`
For example:
```
Compilation error: exit status 1}
```
After this change, the output text is as expected:
```
Compilation error: exit status 1
```
The original location of the project repository was `bcmi-labs/arduino-editor` and some of the internal development
documentation for the project contains references to the repository.
This documentation was not updated at the time the repository was moved to the current home in `arduino/arduino-ide`.
The `carlosperate/download-file-action` action is used in the GitHub Actions workflows as a convenient way to download
external resources.
A major version ref has been added to that repository. It will always point to the latest release of the "1" major
version series. This means it is no longer necessary to do a full pin of the action version in use as before.
Use of the major version ref will cause the workflow to use a stable version of the action, while also benefiting from
ongoing development to the action up until such time as a new major release of an action is made. At that time we would
need to evaluate whether any changes to the workflow are required by the breaking change that triggered the major
release before manually updating the major ref (e.g., uses: `carlosperate/download-file-action@v2`). I think this
approach strikes the right balance between stability and maintainability for these workflows.
* get daemon port from CLI stdout
* config-service to use CLI daemon port
* updating LS
* fixed tests
* fix upload blocked when selectedBoard.port is undefined
* bump arduino-cli to 0.20.2
Co-authored-by: Alberto Iannaccone <a.iannaccone@arduino.cc>
* get serial connection status from BE
* handle serial connect in the BE
* allow breakpoints on vscode (windows)
* Timeout on config change to prevent serial busy
* serial-service tests
* Update Theia to 1.19.0
* update CLI to 0.20.0-rc3
* Add language selector to settings
* updated language server and vscode-arduino-tools
* update Language Server flags
* get cli port from config
* force native menu on windows
* pinned Language Server to rc2
* fix search icon
* update CLI version
* Rebuild gRPC protocol interfaces
* Implement methods to get user fields for board/port combination
* Implement dialog to input board user fields
* Add configure and upload step when uploading to board requiring user fields
* Disable Sketch > Configure and Upload menu if board doesn't support user fields
* Fix serial upload not working with all boards
* Update i18n source file
* fix user fields UI
* regenerate cli protocol
* fix localisation
* check if user fields are empty
Co-authored-by: Alberto Iannaccone <a.iannaccone@arduino.cc>
* Removed Protocol type
* Reworked function that groups ports by protocol
* Remove useless protocol check in Port sameAs function
* Reworked port selection menu ordering
Now ports are shown in this order:
1. Serial with recognized boards
2. Serial with unrecognized boards
3. Network with recognized boards
4. Network with unrecognized boards
5. Other protocols with recognized boards
6. Other protocols with unrecognized boards
* Fix ports shown multiple times in menu
* Reworked board selection dropdown ordering
Ordering is now:
1. Serial with recognized boards
2. Serial with guessed boards
3. Serial with incomplete boards
4. Network with recognized boards
5. Other protocols with recognized boards
* Localize some strings
* Fix bug selecting board in boards selector dropdown
* Reworked board selection dialog ordering
* Fix Tools > Port menu not refreshing
* Move Select other board button to bottom of Board selector dropdown and change its style
* Updated arduino-cli to 0.20.0 and generated protocol files
* spawn new window where to instantiate serial plotter app
* initialize serial monito web app
* connect serial plotter app with websocket
* use npm serial-plotter package
* refactor monitor connection and fix some connection issues
* fix clearConsole + refactor monitor connection
* add serial unit tests
* refactoring and cleaning code
* Properly recognize temporary sketches in macOS
Without this fix, sketches report their URI path as /private/var/xxx
whereas `os.tmpdir()` returns /var/xxx. The second path can be turned
into the first by resolving symlinks, which gives a canonical path to
compare against.
* Open Save as... dialog when saving sketches for the first time
In order to facilitate the testing and review of proposed changes to the repository label infrastructure, the
"Sync Labels" template workflow does a dry run when triggered under conditions that indicate it would not be appropriate
to make real changes to the repository's labels. The changes that would have resulted are printed to the log, but not
actually made.
One of the criteria used to determine "dry run" mode usage is whether the event occurred on the repository's default
branch. A trigger on a development branch or for a pull request should not result in a change to the labels.
It turns out that GitHub does not define a `github.event.repository.default_branch` context item when a workflow is
triggered by a `schedule` event. This resulted in the workflow always running in "dry run" mode on a `schedule` trigger.
Since `schedule` and `repository_dispatch` triggers are only permitted for the default branch, there is no need to check
whether the event's ref matches the default branch and it is safe to always run in write mode on these events.
Incorrect context key name resulted in impossible to satisfy conditional, meaning the dry run determination code was
solely dependent on the check for whether the workflow was triggered from the default branch name.
* integrate cli 0.19.0
* Update CLI version used to fix crash on lib/core install/uninstall
* Update CLI version
* Update CLI version
* update cli version
Co-authored-by: Silvano Cerza <silvanocerza@gmail.com>
On every push that changes relevant files, and periodically, configure the repository's issue and pull request labels
according to the universal, shared, and local label configuration files.
I believe this file name " path src/node/monitor-service-impl.ts " was moved into another folder named monitor, making the correct path for this file here "src/node/monitor/monitor-service-impl.ts"
This will make it easier for the maintainers to sync fixes and improvements in either direction between the upstream
"template" workflow and its installation in this repository.
At the time the workflow was written the authors of the `rtCamp/action-slack-notify` GitHub Actions action did not
provide a major version ref. This meant that it was necessary to pin the action to a specific version.
Since then, a few new releases have been made, meaning an outdated version of the action was in use as a consequence of
the pinning.
The action now offers a `v2` major ref. Use of this ref will cause the workflow to benefit from ongoing development to
the action up until such time as a new major release is made, at which time we would need to evaluate whether any changes
to the workflow are required by the breaking change that triggered the major release before updating the major ref
(e.g., `uses: rtCamp/action-slack-notify@v3`).
The "Check Certificates" workflow is configured to send a notification via Slack if a problem is found with a certificate.
TThis is currently posted to the `team_tooling` channel, but that is not necessarily always going to be the case, and for
every deployment of the workflow. So a less specific secret name is more universally applicable to serve all applications
of this "template" workflow.
No functional change, and neither is necessarily superior, but this is the formatting style either defined in the
"template", or by the repository's Prettier formatting configuration preferences, so it must be brought into compliance
here as well.
When no name is provided for a matrix job, the workflow job is named according to the contents of
`jobs[].<job_id>.strategy.matrix[]`. That can result in some fairly cryptic job names when the matrix contains a complex
data structure as is the case here. We already have a string to uniquely identify each certificate to humans, which is
exactly what the `jobs[].<job_id>.name` property does for jobs, so it will be an improvement to name the jobs according
to that identifier.
This will facilitate testing and review of modifications to the workflow.
Because the workflow requires access to repository secrets, and so will fail whenever triggered by an event from a fork,
a conditional is added to make it only run when the modifications are made within the `arduino/arduino-ide`
repository.
The `repository_dispatch` event allows triggering workflows via the GitHub API. This might be useful for triggering an
immediate check in multiple relevant repositories after an external change, or some automated process. Although we don't
have any specific need for this event at the moment, the event has no impact on the workflow, so there is no reason
against having it. It is the sort of thing that can end up being useful if it is already in consistently in place, but
not worth setting up on demand, since the effort to set it up is greater than the effort to trigger all the workflows
manually.
* improve push/pull process
* improved diff tree performance generation
* skip some files to be synced
Co-authored-by: Francesco Stasi <f.stasi@me.com>
handle cornercase when 2 packages are associated to the same board
updated cli version and grpc
support deprecated cores in the boards manager
bump cli version
Bump ArduinoCLI version to latest release
Add package version in notification
Like for the examples, we show all libraries if no board is selected,
or the platform for the selected board is not installed.
Otherwise, we show the libs for the current board.
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
Show all examples:
- when no board is selected,
- when the core is not installed for the selected board.
Otherwise, show examples for the currently selected board only.
Only get libraries from the cores when the FQBN is defined.
Otherwise, we retrieve user installed libraries only.
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
The "Arduino IDE" workflow was updated to produce individual artifacts for each operating system, but the development
documentation was not updated accordingly at that time.
The "Arduino IDE" GitHub Actions workflow uses a workflow artifact to transfer the build artifacts between jobs. Now that
separate tester build artifacts are produced, the monolithic job transfer artifact is superfluous once the workflow run
is finished. Deleting it avoids potential confusion for beta testers and unnecessary storage space usage.
Previously, a single workflow artifact was created by the "Arduino IDE" GitHub Actions workflow. This artifact contained
the builds for each operating system, including all three versions of the Windows build. This resulted in beta testers
needing to do a >1 GB download for every build, even though they likely needed only ~200 MB of what they downloaded.
Producing separate workflows makes it easier for beta testers to participate in the development and is less wasteful of
resources.
Previously, the build CI/CD workflow had many occurrences of the string "build-artifacts" used for the workflow artifact
name. This made the workflow more difficult to understand and maintain. Now a single workflow scoped environment variable
is used to define the artifact name.
fix hover state on toolbar items
Improved statemanagement for ToolbarItem and Menus
Disable Upload buttons while a sketch upload is already in progress
toggled state to have override disabled button opacity
doublecheck internal status before verify/upload a sketch
fixes after code review
- Skip Mac/Win code signing and Apple notarization only if PR comes from a fork
- Disable workflows entirely if the user enabled Github Actions in
their fork repo
- Add steps to help Mac users to test their forked code in BUILDING.md
Previously, when gRPC client creation failed, the incorrect error message was shown:
root ERROR Could create client for gRPC.
When the message is intended to have the opposite meaning.
Fall back to the current sketch, if `currentWidget` points to a file
outside of the workspace.
Closes: arduino/arduino-ide#46
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
* Update README
* Some more changes to README
* Add anchor to link to Arduino Software Download page Section for IDE 2.0
Co-authored-by: Roberto Sora <r.sora@arduino.cc>
- Added a 20 sec timeout to the LS process start.
- Discard running LS FQBN when the LS start has failed.
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
This repositories label names have been customized. The label names defined in the templates will automatically be added
to issues created using that template, so the template labels must match with the repository's labeling convention.
The bug report template provides some example values for OS and version. The previous examples were completely
irrelevant to this project due to using an unsupported OS and a different versioning scheme. This might cause confusion,
or at least seem odd, to the contributor.
At the first step of creating an issue, a menu of issue types will be presented:
- Bug report
- Feature request
- Report a security vulnerability
If one of the first two are selected, the issue body field will be pre-filled with the template Markdown.
"Report a security vulnerability" will take them to Arduino's global security disclosure policy, which provides further guidance.
If none of the categories in the issue type chooser are applicable, the "Open a blank issue." link at the bottom of the
page can be selected, which will provide the non-templated issue creation experience.
These templates are copies of https://github.com/arduino/arduino-pro-ide/tree/master/.github/ISSUE_TEMPLATE
- Log the PID of the backend process.
- Aligned the dev startup mode with the production: `--no-cluster`.
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
- Fixed a monitor reconnecting issue after upload.
- Serial monitor connection was not disposed when the widget was closed
from the toolbar with the magnifier (🔍) icon. It worked only iff the
user closed the view with the `X`.
- This commit also fixes a warning that was related to the incorrect focus
handling of the widget.
- Switched to `board list -w` instead of polling.
- Added a singleton for the board discovery to spare the CPU.
- Fixed DI scopes on the backend. Each frontend gets its own service.
- Switched to the `20201112` nightly CLI.
- Fixed the Monitor view's image when the view is on the side-bar.
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
Made the port/fqbn/programmer optional for upload, verify,
and burn bootloader. From now on, the IDE does not warn the user before
performing the desired CLI command.
Closesarduino/arduino-pro-ide#364
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
- Pinned the CLI to the `20201104` nightly.
- Updated the TS/JS API generator to fall back to forks if configured.
- Updated the CLI JSON schema.
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
An error in the crontab configuration resulted in the `schedule` event triggered workflow running every 6-9 minutes (the minimum interval GitHub Actions provides) for the duration of every tenth hour.
The updated crontab causes the workflow to run once every 10 hours, as intended.
If the macOS or Windows signing certificates fail verification, a notification will be posted on the #team_tooling Slack channel.
If the certificates expire in less than 30 days, a notification will be posted on the #team_tooling Slack channel.
It was previously required to use the `windows-2016` runner to build Arduino Pro IDE. That is no longer necessary and
Windows signing fails when using that runner.
We consider a build as nightly, if was started by the
CRON job, or was manually triggered from the master
branch.
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
Instead of passing the FS path (`string`) to the `LoadSketch` method,
we have to convert it into a proper URI string.
Closesarduino/arduino-pro-ide#311
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
When you have multiple snapshot builds on your computer for testing purposes, it's difficult to keep track of which is which. The commit hash is shown by the running application, but it's more convenient to have the installation also identified by its folder name.
Adding the short commit hash to the build archive filename (and thus the extracted folder name) provides a clear identifier for each build.
Before this change, the archive is named like:
arduino-pro-ide_snapshot_Linux_64bit.zip
after:
arduino-pro-ide_0.0.7-snapshot.1b8c510_Linux_64bit.zip
instead otf reloaading the current window, we open a new one
and close the current.
reloading the current window hangs on electron in Windows env.
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
When uploading using a programmer, the port is ignored by the CLI.
Also removed `programmer` from compile request [arduino/arduino-cli#861]
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
The self hosted runner was used because the electron-builder signing process was hanging when the workflow was run on the GitHub hosted macOS runner. Now that the electron-builder signing certificate import procedure can be used, the GitHub hosted runner can be used without any problems so there is no longer any need for a self hosted runner.
The previous certificate import system causes electron-builder's code signing process to hang when the GitHub hosted macOS runner is used.
electron-builder has a built-in system for importing the code signing certificate into the keychain. This requires the certificate to have been exported using a specific procedure, which is described vaguely in the electron-builder documentation:
https://www.electron.build/code-signing
And more thoroughly in this article:
https://www.kencochrane.com/2020/08/01/build-and-sign-golang-binaries-for-macos-with-github-actions/#exporting-the-developer-certificate
The "KEYCHAIN" secret that was previously in use was apparently produced by some other procedure. The use of that secret results in a "security: SecKeychainItemImport: Unknown format in import." error during the electron-builder's certificate import process. The APPLE_SIGNING_CERTIFICATE_P12 secret was generated by following the instructions in the article at the link above and works fine with the electron-builder certificate import system.
From now on, sketches are created in the temp folder,
and will be moved to the `directories.user` location
when the user performs a manual `Save`.
A new sketch can be created with the `CtrlCmd+N` binding.
Closes: arduino/arduino-pro-ide#260Closes: arduino/arduino-pro-ide#261
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
This change is required to be able to support ARM arch
in the future.
- Fixed the download links for armv7l Linux.
- Checked in the generated code. [grpc/grpc-node#1497]
- Made the code generation a manual step.
- Made the `grpc-tools` dependency optional.
- From now on, the serial port regex is case-insensitive.
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
- [macOS] Removed `zip` target. We need it later for the auto-update.
- [CI]: From now on, the release tag must not start with `v`.
- [yarn]: Added steps on how to rebuild the natives from the source.
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
- Split up the pipeline to build, publish, and release.
- Set a 30 minutes build timeout, to avoid macOS signing issues.
- Removed global envs. `env` cannot be accessed for `if` in jobs.
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
- Aligned the daemon test to latest `js-yaml`.
- Aligned the TS version with Theia.
- Resolved a dependency-cycle with `next` Theia.
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
Also bumped up the `lerna` dependency as it mysteriously made the
`nsfw` module re-build incorrectly for electron and caused a runtime
error due to missing `lodash.isnumber` dependency.
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
- Support for multiple electron targe per platform.
- Removed packager CLI. Changed the logic we calculate the app name.
- Fixed various OS-specific tests: stubbed `os`.
- Restructured the final ZIP formats for Windows and Linux.
- Added packager tests.
- Switched from `@grpc/grpc-js` to native `grpc`.
- Updated the version from 0.0.5 to 0.0.6.
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
Tests whether the current workspace is a sketchfolder and
opens the respective ino file
or whether the current editor is a ino file.
Signed-off-by: jbicker <jan.bicker@typefox.io>
Fixed the color for the:
- selected items in the Explorer,
- warning `input`s,
- set custom dialog background for the Arduino theme,
- the query term matches in the command palette, and
- react-select.
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
- Updated to next Theia,
- Added elecron launch config,
- Yet another syling for the input + selects,
- Close monitor connection on widget close not detach.
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
We have to pick the installed version first.
Otherwise we lose the FQBN of the boards.
FBQN is used to check if a board has the corresponding core installed.
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
- Do not reset the layout. It messes up the editor's restoration.
- Close all pro-mode only views when leaving pro-mode.
- Initialize all views `onStart`. It is a NOOP in normal mode.
Closesarduino/arduino-pro-ide#101
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
From now on, we do not retrieve the ports from the attached boards.
A board can be unknown but the port is still relevant.
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
Got rid of the `sketch` search parameter from the URL.
Rules:
- Get the desired workspace location from the
- `Path` defined as the `window.location.hash` of the URL,
- most recent workspaces,
- most recent sketches from the default sketch folder.
- Validate the location.
- If no valid location was found, create a new sketch in the default sketch folder.
Note: when validating the location of the workspace root, the root must always exist. However, when in pro-mode, the desired workspace root must
not be a sketch directory with the `.ino` file, but can be any existing location.
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
- We have to reuse the `yarn.lock` file for the final app, not just
for the extensions.
- Simplified the clean-up phase.
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
- From now on, sources from the `dataDir` opened in a read-only editor.
- Disabled the tab-bar decoration for built-ins.
- No problem markers for the built-ins.
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
Fine tuned the port unnselection when attached boards change.
This should make sure we do not have to `await` for the attached boards
from the backend.
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
```
info There appears to be trouble with your network connection. Retrying...
error An unexpected error occurred: "https://registry.yarnpkg.com/rxjs/-/rxjs-6.5.2.tgz: ESOCKETTIMEDOUT".
info If you think this is a bug, please open a bug report with the information provided in "D:\\a\\1\\s\\yarn-error.log".
```
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
When opening sketches. Rules:
- If `sketch` is missing from the URL, we reuse the same window.
- NOOP, if we try to open the currently opened sketch.
- Otherwise, use the existing logic: open sketch in a new window.
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
From now on, we spawn a detached process that
will periodically check whether the parent Theia
the process is alive, if no, terminates the daemon.
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
- From now on, each new sketch has its own window.
- Fixed the `Download (of)? X completed` logging during index update.
- Validate the file before opening the sketch in new window.
Signed-off-by: Akos Kitta <kittaakos@typefox.io>
This repo contains a proof-of-concept for an Arduino IDE based on Theia.
It's built on top of a [fork of the arduino-cli](https://github.com/typefox/arduino-cli/tree/daemon) that sports a gRPC interface.
This repository contains the source code of the Arduino IDE 2.x. If you're looking for the old IDE, go to the [repository of the 1.x version](https://github.com/arduino/Arduino).
## How to try (offline)
The Arduino IDE 2.x is a major rewrite, sharing no code with the IDE 1.x. It is based on the [Theia IDE](https://theia-ide.org/) framework and built with [Electron](https://www.electronjs.org/). The backend operations such as compilation and uploading are offloaded to an [arduino-cli](https://github.com/arduino/arduino-cli) instance running in daemon mode. This new IDE was developed with the goal of preserving the same interface and user experience of the previous major version in order to provide a frictionless upgrade.
If you want to switch back to the browser-based example, execute the following in the repository root
```
yarn rebuild:browser
```
Then you can start the browser example again:
```
yarn --cwd arduino-ide-browser start
```
## Download
## Arduino-PoC Electron Application
The project is built on [Azure DevOps](https://dev.azure.com/typefox/Arduino).
You can download the latest release version and nightly builds from the [software download page on the Arduino website](https://www.arduino.cc/en/software).
Currently, we provide the Arduino-PoC for the following platforms:
- Windows,
- macOS, and
- Linux.
You can download the latest release applications fom [here](https://github.com/bcmi-labs/arduino-editor/releases/latest).
If you want to get a nightly build, go to the [Azure DevOps page](https://dev.azure.com/typefox/Arduino/_build?definitionId=4),
and follow the steps from below.
## Support
If you need assistance, see the [Help Center](https://support.arduino.cc/hc/en-us/categories/360002212660-Software-and-Downloads) and browse the [forum](https://forum.arduino.cc/index.php?board=150.0).
Click [here](./electron/README.md) for more details on the CI/CD, the GitHub release, and the build process in general.
## Bugs & Issues
If you want to report an issue, you can submit it to the [issue tracker](https://github.com/arduino/arduino-ide/issues) of this repository.
See [**the issue report guide**](docs/contributor-guide/issues.md#issue-report-guide) for instructions.
### Security
If you think you found a vulnerability or other security-related bug in this project, please read our
[security policy](https://github.com/arduino/arduino-ide/security/policy) and report the bug to our Security Team 🛡️
Thank you!
e-mail contact: security@arduino.cc
## Contributions and development
Contributions are very welcome! There are several ways to participate in this project, including:
- Fixing bugs
- Beta testing
- Translation
See [**the contributor guide**](docs/CONTRIBUTING.md#contributor-guide) for more information.
See the [**development guide**](docs/development.md) for a technical overview of the application and instructions for building the code.
### Support the project
This open source code was written by the Arduino team and is maintained on a daily basis with the help of the community. We invest a considerable amount of time in development, testing and optimization. Please consider [buying original Arduino boards](https://store.arduino.cc/) to support our work on the project.
## License
The code contained in this repository and the executable distributions are licensed under the terms of the GNU AGPLv3. The executable distributions contain third-party code licensed under other compatible licenses such as GPLv2, MIT and BSD-3. If you have questions about licensing please contact us at [license@arduino.cc](mailto:license@arduino.cc).
Arduino IDE is based on Theia, and most of its IDE features, UIs and customizations are implemented in this Theia extension.
### IDE Services
IDE services typically have a backend part in [src/node/](./src/node/) and a front-end part in [src/browser/](./src/browser/).
#### Boards Service
The Boards Service continuously checks the computer's ports, in order to detect when you connect or disconnect an Arduino board.
The Boards Manager lists all the known board types, and allows downloading new cores to get additional board types.
- [src/common/protocol/boards-service.ts](./src/common/protocol/boards-service.ts) implements the common classes and interfaces
- [src/node/boards-service-impl.ts](./src/node/boards-service-impl.ts) implements the service backend:
- discovering ports & boards
- searching for compatible board types
- installing new board types
- [src/browser/boards/boards-list-widget.ts](./src/browser/boards/boards-service-client-impl.ts) implements the Boards Manager front-end:
- browsing/searching available board types
- installing new board types
#### Core Service
The Core Service is responsible for building your sketches and uploading them to a board.
- [src/common/protocol/core-service.ts](./src/common/protocol/core-service.ts) implements the common classes and interfaces
- [src/node/core-service-impl.ts](./src/node/core-service-impl.ts) implements the service backend:
- compiling a sketch for a selected board type
- uploading a sketch to a connected board
#### Serial Service
The Serial Service allows getting information back from sketches running on your Arduino boards.
- [src/common/protocol/serial-service.ts](./src/common/protocol/serial-service.ts) implements the common classes and interfaces
- [src/node/serial/serial-service-impl.ts](./src/node/serial/serial-service-impl.ts) implements the service backend:
- connecting to / disconnecting from a board
- receiving and sending data
- [src/browser/serial/serial-connection-manager.ts](./src/browser/serial/serial-connection-manager.ts) handles the serial connection in the frontend
- [src/browser/serial/monitor/monitor-widget.tsx](./src/browser/serial/monitor/monitor-widget.tsx) implements the serial monitor front-end:
- viewing the output from a connected board
- entering data to send to the board
- [src/browser/serial/plotter/plotter-frontend-contribution.ts](./src/browser/serial/plotter/plotter-frontend-contribution.ts) implements the serial plotter front-end:
- opening a new window running the [Serial Plotter Web App](https://github.com/arduino/arduino-serial-plotter-webapp)
#### Config Service
The Config Service knows about your system, like for example the default sketch locations.
- [src/common/protocol/config-service.ts](./src/common/protocol/config-service.ts) implements the common classes and interfaces
- [src/node/config-service-impl.ts](./src/node/config-service-impl.ts) implements the service backend:
- getting the `arduino-cli` version and configuration
- checking whether a file is in a data or sketch directory
### `"arduino"` configuration in the `package.json`:
-`"cli"`:
-`"version"` type `string` | `{ owner: string, repo: string, commitish?: string }`: if the type is a `string` and is a valid semver, it will get the corresponding [released](https://github.com/arduino/arduino-cli/releases) CLI. If the type is `string` and is a [date in `YYYYMMDD`](https://arduino.github.io/arduino-cli/latest/installation/#nightly-builds) format, it will get a nightly CLI. If the type is an object, a CLI, build from the sources in the `owner/repo` will be used. If `commitish` is not defined, the HEAD of the default branch will be used. In any other cases an error is thrown.
#### Rebuild gRPC protocol interfaces
- Some CLI updates can bring changes to the gRPC interfaces, as the API might change. gRPC interfaces can be updated running the command
The [**clangd** C++ language server](https://clangd.llvm.org/) and the [**ClangFormat** code formatter](https://clang.llvm.org/docs/ClangFormat.html) tool dependencies are managed in parallel. Updating them to a different version is done by the following procedure:
1. If the target version is not already [available from the `arduino/clang-static-binaries` repository](https://github.com/arduino/clang-static-binaries/releases), submit [an issue there](https://github.com/arduino/clang-static-binaries/issues) requesting a build and wait for that to be completed.
1. Validate the **ClangFormat** configuration for the target version by following the instructions [**here**](https://github.com/arduino/tooling-project-assets/tree/main/other/clang-format-configuration#clangformat-version-updates)
1. Submit a pull request in the `arduino/arduino-ide` repository to update the version in the `arduino.clangd.version` key of [`package.json`](package.json).
1. Submit a pull request in [the `arduino/tooling-project-assets` repository](https://github.com/arduino/tooling-project-assets) to update the version in the `vars.DEFAULT_CLANG_FORMAT_VERSION` field of [`Taskfile.yml`](https://github.com/arduino/tooling-project-assets/blob/main/Taskfile.yml).
### Customize Icons
ArduinoIde uses a customized version of FontAwesome.
In order to update/replace icons follow the following steps:
- import the file `arduino-icons.json` in [Icomoon](https://icomoon.io/app/#/projects)
- load it
- edit the icons as needed
- !! download the **new**`arduino-icons.json` file and put it in this repo
- Click on "Generate Font" in Icomoon, then download
- place the updated fonts in the `src/style/fonts` directory
`Failed to execute ${command} with args: ${JSON.stringify(args)}`
);
throwerr;
}
};
exports.exec=exec;
/**
* Clones something from GitHub and builds it with [`Task`](https://taskfile.dev/).
*
* @param version {object} the version object.
* @param destinationPath {string} the absolute path of the output binary. For example, `C:\\folder\\arduino-cli.exe` or `/path/to/arduino-language-server`
* @param taskName {string} for the CLI logging . Can be `'CLI'` or `'language-server'`, etc.
* Clones something from GitHub and builds it with `Golang`.
*
* @param version {object} the version object.
* @param destinationPath {string} the absolute path of the output binary. For example, `C:\\folder\\arduino-cli.exe` or `/path/to/arduino-language-server`
* @param taskName {string} for the CLI logging . Can be `'CLI'` or `'language-server'`, etc.
// This is a hack. Otherwise, the backend services won't bind.
awaitthis.workspaceServiceExt.roots();
@postConstruct()
protectedinit():void{
if(!window.navigator.onLine){
// tslint:disable-next-line:max-line-length
this.messageService.warn(
nls.localize(
'arduino/common/offlineIndicator',
'You appear to be offline. Without an Internet connection, the Arduino CLI might not be able to download the required resources and could cause malfunction. Please connect to the Internet and restart the application.'
"If true, the language server provides real-time diagnostics when typing in the editor. It's false by default."
),
default:false,
},
'arduino.language.asyncWorkers':{
type:'number',
description: nls.localize(
'arduino/preferences/language.asyncWorkers',
'Number of async workers used by the Arduino Language Server (clangd). Background index also uses this many workers. The minimum value is 0, and the maximum is 8. When it is 0, the language server uses all available cores. The default value is 0.'
),
minimum: minAsyncWorkers,
maximum: maxAsyncWorkers,
default:defaultAsyncWorkers,
},
'arduino.compile.verbose':{
type:'boolean',
description: nls.localize(
'arduino/preferences/compile.verbose',
'True for verbose compile output. False by default'
),
default:false,
},
'arduino.compile.experimental':{
type:'boolean',
description: nls.localize(
'arduino/preferences/compile.experimental',
'True if the IDE should handle multiple compiler errors. False by default'
),
default:false,
},
'arduino.compile.revealRange':{
enum:[...ErrorRevealStrategyLiterals],
description: nls.localize(
'arduino/preferences/compile.revealRange',
"Adjusts how compiler errors are revealed in the editor after a failed verify/upload. Possible values: 'auto': Scroll vertically as necessary and reveal a line. 'center': Scroll vertically as necessary and reveal a line centered vertically. 'top': Scroll vertically as necessary and reveal a line close to the top of the viewport, optimized for viewing a code definition. 'centerIfOutsideViewport': Scroll vertically as necessary and reveal a line centered vertically only if it lies outside the viewport. The default value is '{0}'.",
ErrorRevealStrategy.Default
),
default:ErrorRevealStrategy.Default,
},
'arduino.compile.warnings':{
enum:[...CompilerWarningLiterals],
description: nls.localize(
'arduino/preferences/compile.warnings',
"Tells gcc which warning level to use. It's 'None' by default"
),
default:'None',
},
'arduino.upload.verbose':{
type:'boolean',
description: nls.localize(
'arduino/preferences/upload.verbose',
'True for verbose upload output. False by default.'
),
default:false,
},
'arduino.upload.verify':{
type:'boolean',
default:false,
description: nls.localize(
'arduino/preferences/upload.verify',
'After upload, verify that the contents of the memory on the board match the uploaded binary.'
),
},
'arduino.upload.autoVerify':{
type:'boolean',
default:true,
description: nls.localize(
'arduino/preferences/upload.autoVerify',
"True if the IDE should automatically verify the code before the upload. True by default. When this value is false, IDE does not recompile the code before uploading the binary to the board. It's highly advised to only set this value to false if you know what you are doing."
),
},
'arduino.window.autoScale':{
type:'boolean',
description: nls.localize(
'arduino/preferences/window.autoScale',
'True if the user interface automatically scales with the font size.'
"Enable debug logging of the gRPC calls to the Arduino CLI. A restart of the IDE is needed for this setting to take effect. It's false by default."
),
default:false,
},
'arduino.checkForUpdates':{
type:'boolean',
description: nls.localize(
'arduino/preferences/checkForUpdate',
"Receive notifications of available updates for the IDE, boards, and libraries. Requires an IDE restart after change. It's true by default."
),
default:true,
},
'arduino.sketch.inoBlueprint':{
type:'string',
markdownDescription: nls.localize(
'arduino/preferences/sketch/inoBlueprint',
'Absolute filesystem path to the default `.ino` blueprint file. If specified, the content of the blueprint file will be used for every new sketch created by the IDE. The sketches will be generated with the default Arduino content if not specified. Unaccessible blueprint files are ignored. **A restart of the IDE is needed** for this setting to take effect.'
),
default:undefined,
},
'arduino.monitor.dockPanel':{
type:'string',
enum:['bottom','right'],
markdownDescription: nls.localize(
'arduino/preferences/monitor/dockPanel',
'The area of the application shell where the _{0}_ widget will reside. It is either "bottom" or "right". It defaults to "{1}".',
// IDE2 knows that selected board is not installed. Look for board `name` match in not yet installed platforms.
// The order should be correct when there is a board name collision (e.g. Arduino Nano RP2040 from Arduino Mbed OS Nano Boards, [DEPRECATED] Arduino Mbed OS Nano Boards). The CLI boosts the platforms, so picking the first name match should be fine.
// When `@theia/workspace` is part of the application, the workspace-scoped storage service is the default implementation, and the `StorageService` symbol must be used for the injection.
// In other words, store the data (such as the board configs) per sketch, not per IDE2 installation. https://github.com/arduino/arduino-ide/issues/2240
"Could not find previously selected board '{0}' in installed platform '{1}'. Please manually reselect the board you want to use. Do you want to reselect it now?",
// to avoid flickering, reveal the range here and not with `getByUri`, because it uses `at: 'center'` for the reveal option.
// TODO: check the community reaction whether it is better to set the focus at the error marker. it might cause flickering even if errors are close to each other
"Sketch '{0}' must be verified before starting a debug session. Please verify the sketch and start debugging again. Do you want to verify the sketch now?",
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
