Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: arduino/arduino-ide
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: 2.3.3
Choose a base ref
...
head repository: arduino/arduino-ide
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: 2.3.4
Choose a head ref

Commits on Oct 22, 2024

  1. Bump version metadata post release

    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.
    per1234 committed Oct 22, 2024
    Copy the full SHA
    91bb75c View commit details
  2. fix: prevent parsing CLI errors without metadata

    When parsing a CLI error, check if any metadata from grpc is present before trying to parse it.
    Closes #2516
    giacomocusinato authored and per1234 committed Oct 22, 2024
    Copy the full SHA
    4a3abf5 View commit details

Commits on Oct 24, 2024

  1. Copy the full SHA
    44f1523 View commit details

Commits on Oct 27, 2024

  1. fix(doc): add missing prerequisites to dev docs (#2531)

    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>
    dankeboy36 and per1234 authored Oct 27, 2024
    Copy the full SHA
    3ccc864 View commit details

Commits on Nov 11, 2024

  1. Copy the full SHA
    63e9dfd View commit details

Commits on Nov 17, 2024

  1. Copy the full SHA
    9cbee0e View commit details
  2. Add PAID_RUNNER_BUILD_DATA environment variable back to build workflow

    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.
    per1234 committed Nov 17, 2024
    Copy the full SHA
    3d82cb3 View commit details
  3. Simplify and generalize configurable working directory code in build …

    …workflow
    
    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.
    per1234 committed Nov 17, 2024
    Copy the full SHA
    c0b0b84 View commit details
  4. Use appropriate indicator for dependency installation conditionals in…

    … build workflow
    
    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).
    per1234 committed Nov 17, 2024
    Copy the full SHA
    43f0ccb View commit details

Commits on Nov 18, 2024

  1. Get job-specific configuration from matrix in build workflow

    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.
    per1234 committed Nov 18, 2024
    Copy the full SHA
    0fe0fea View commit details
  2. Use appropriate indicator for Windows signing determination in build …

    …workflow
    
    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.
    per1234 committed Nov 18, 2024
    Copy the full SHA
    f72d1f0 View commit details
  3. Remove redundant signing determination code from build system

    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.
    per1234 committed Nov 18, 2024
    Copy the full SHA
    4f8b980 View commit details
  4. Use a dedicated GitHub Actions workflow for linting TypeScript/JavaSc…

    …ript code
    
    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.
    per1234 committed Nov 18, 2024
    Copy the full SHA
    6e69542 View commit details
  5. Use a dedicated GitHub Actions workflow for testing TypeScript/JavaSc…

    …ript code
    
    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.
    per1234 committed Nov 18, 2024
    Copy the full SHA
    9331d2e View commit details
  6. Use a dedicated GitHub workflow to check for problems with Yarn confi…

    …guration
    
    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.
    per1234 committed Nov 18, 2024
    Copy the full SHA
    788017b View commit details

Commits on Nov 19, 2024

  1. Correct eslint command in lint script

    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.
    per1234 committed Nov 19, 2024
    Copy the full SHA
    f232010 View commit details
  2. Use appropriate equality operator in changelog script

    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
    per1234 committed Nov 19, 2024
    Copy the full SHA
    d377d00 View commit details
  3. build(deps): Bump svenstaro/upload-release-action from 2.7.0 to 2.9.0

    Bumps [svenstaro/upload-release-action](https://github.com/svenstaro/upload-release-action) from 2.7.0 to 2.9.0.
    - [Release notes](https://github.com/svenstaro/upload-release-action/releases)
    - [Changelog](https://github.com/svenstaro/upload-release-action/blob/master/CHANGELOG.md)
    - [Commits](svenstaro/upload-release-action@2.7.0...2.9.0)
    
    ---
    updated-dependencies:
    - dependency-name: svenstaro/upload-release-action
      dependency-type: direct:production
      update-type: version-update:semver-minor
    ...
    
    Signed-off-by: dependabot[bot] <support@github.com>
    dependabot[bot] authored and per1234 committed Nov 19, 2024
    Copy the full SHA
    d6235f0 View commit details

Commits on Nov 21, 2024

  1. fix: memory leak when scanning sketchbooks with large files (#2555)

    Resolves #2537
    
    Fix memory leak issue caused by inflight dependency, see isaacs/node-glob#435
    giacomocusinato authored Nov 21, 2024
    Copy the full SHA
    7c231ff View commit details
  2. Copy the full SHA
    41844c9 View commit details
  3. fix: retry compilation if grpc client needs to be reinitialized (#2548)

    * 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 #2547
    giacomocusinato authored Nov 21, 2024
    Copy the full SHA
    4cf9909 View commit details
  4. fix: align viewsWelcome behavior to VS Code (#2543)

    * fix: align `viewsWelcome` behavior to VS Code
    
    Ref: eclipse-theia/theia#14309
    Signed-off-by: dankeboy36 <dankeboy36@gmail.com>
    
    * fix: update change proposal from Theia as is
    
    Ref: #2543
    Signed-off-by: dankeboy36 <dankeboy36@gmail.com>
    
    ---------
    
    Signed-off-by: dankeboy36 <dankeboy36@gmail.com>
    dankeboy36 authored Nov 21, 2024
    Copy the full SHA
    3fc8474 View commit details
  5. fix: update yarn.lock

    giacomocusinato committed Nov 21, 2024
    Copy the full SHA
    4189b08 View commit details
  6. Copy the full SHA
    8773bd6 View commit details
  7. Copy the full SHA
    d106588 View commit details

Commits on Nov 26, 2024

  1. feat: can skip verify before upload

    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>
    dankeboy36 authored and giacomocusinato committed Nov 26, 2024
    Copy the full SHA
    48d6d37 View commit details

Commits on Nov 27, 2024

  1. refactor: generate-protocol now fetch proto files from `arduino_cli…

    …_{version}_proto.zip`
    
    - 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 arduino/arduino-cli#2761
    giacomocusinato committed Nov 27, 2024
    Copy the full SHA
    8462d8a View commit details
  2. Copy the full SHA
    de26569 View commit details
  3. build(deps): Bump actions/upload-artifact from 3 to 4

    Bumps [actions/upload-artifact](https://github.com/actions/upload-artifact) from 3 to 4.
    - [Release notes](https://github.com/actions/upload-artifact/releases)
    - [Commits](actions/upload-artifact@v3...v4)
    
    ---
    updated-dependencies:
    - dependency-name: actions/upload-artifact
      dependency-type: direct:production
      update-type: version-update:semver-major
    ...
    
    Signed-off-by: dependabot[bot] <support@github.com>
    dependabot[bot] authored and per1234 committed Nov 27, 2024
    Copy the full SHA
    86c7fd7 View commit details
  4. build(deps): Bump actions/download-artifact from 3 to 4

    Bumps [actions/download-artifact](https://github.com/actions/download-artifact) from 3 to 4.
    - [Release notes](https://github.com/actions/download-artifact/releases)
    - [Commits](actions/download-artifact@v3...v4)
    
    ---
    updated-dependencies:
    - dependency-name: actions/download-artifact
      dependency-type: direct:production
      update-type: version-update:semver-major
    ...
    
    Signed-off-by: dependabot[bot] <support@github.com>
    dependabot[bot] authored and per1234 committed Nov 27, 2024
    Copy the full SHA
    84d2dfd View commit details
  5. build(deps): Bump geekyeggo/delete-artifact from 2 to 5

    Bumps [geekyeggo/delete-artifact](https://github.com/geekyeggo/delete-artifact) from 2 to 5.
    - [Release notes](https://github.com/geekyeggo/delete-artifact/releases)
    - [Changelog](https://github.com/GeekyEggo/delete-artifact/blob/main/CHANGELOG.md)
    - [Commits](GeekyEggo/delete-artifact@v2...v5)
    
    ---
    updated-dependencies:
    - dependency-name: geekyeggo/delete-artifact
      dependency-type: direct:production
      update-type: version-update:semver-major
    ...
    
    Signed-off-by: dependabot[bot] <support@github.com>
    dependabot[bot] authored and per1234 committed Nov 27, 2024
    Copy the full SHA
    0aec778 View commit details
  6. Don't upload multiple times to same artifact in label sync workflow

    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.
    per1234 committed Nov 27, 2024
    Copy the full SHA
    90d3d77 View commit details
  7. Don't upload multiple times to same artifact in build workflow

    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.
    per1234 committed Nov 27, 2024
    Copy the full SHA
    dba57b3 View commit details
  8. Use Ubuntu 18.10 in Linux build container

    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)
    ```
    per1234 committed Nov 27, 2024
    Copy the full SHA
    c09b5f7 View commit details

Commits on Nov 29, 2024

  1. build(deps): Bump peter-evans/create-pull-request from 5 to 7

    Bumps [peter-evans/create-pull-request](https://github.com/peter-evans/create-pull-request) from 5 to 7.
    - [Release notes](https://github.com/peter-evans/create-pull-request/releases)
    - [Commits](peter-evans/create-pull-request@v5...v7)
    
    ---
    updated-dependencies:
    - dependency-name: peter-evans/create-pull-request
      dependency-type: direct:production
      update-type: version-update:semver-major
    ...
    
    Signed-off-by: dependabot[bot] <support@github.com>
    dependabot[bot] authored and per1234 committed Nov 29, 2024
    Copy the full SHA
    284dd83 View commit details
  2. build(deps): Bump docker/build-push-action from 5 to 6

    Bumps [docker/build-push-action](https://github.com/docker/build-push-action) from 5 to 6.
    - [Release notes](https://github.com/docker/build-push-action/releases)
    - [Commits](docker/build-push-action@v5...v6)
    
    ---
    updated-dependencies:
    - dependency-name: docker/build-push-action
      dependency-type: direct:production
      update-type: version-update:semver-major
    ...
    
    Signed-off-by: dependabot[bot] <support@github.com>
    dependabot[bot] authored and per1234 committed Nov 29, 2024
    Copy the full SHA
    3aedafa View commit details

Commits on Dec 2, 2024

  1. Copy the full SHA
    71b11ed View commit details
  2. feat: introduce VersionWelcomeDialog

    Show donate dialog after the first time a first IDE version is loaded
    giacomocusinato committed Dec 2, 2024
    Copy the full SHA
    4788bfb View commit details
  3. feat: use dompurify to sanitize translations

    Pin same version of `dompurify` used in Theia
    giacomocusinato committed Dec 2, 2024
    Copy the full SHA
    8e18c47 View commit details
  4. Updated translation files (#2523)

    Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
    github-actions[bot] authored Dec 2, 2024
    Copy the full SHA
    1112057 View commit details
Showing with 3,617 additions and 975 deletions.
  1. +22 −71 .github/workflows/assets/linux.Dockerfile
  2. +94 −89 .github/workflows/build.yml
  3. +1 −1 .github/workflows/check-containers.yml
  4. +88 −0 .github/workflows/check-javascript.yml
  5. +91 −0 .github/workflows/check-yarn.yml
  6. +1 −1 .github/workflows/i18n-weekly-pull.yml
  7. +1 −1 .github/workflows/push-container-images.yml
  8. +10 −9 .github/workflows/sync-labels.yml
  9. +134 −0 .github/workflows/test-javascript.yml
  10. +1 −1 .github/workflows/themes-weekly-pull.yml
  11. +3 −1 README.md
  12. +8 −6 arduino-ide-extension/package.json
  13. +1 −1 arduino-ide-extension/scripts/compose-changelog.js
  14. +188 −97 arduino-ide-extension/scripts/generate-protocol.js
  15. +64 −1 arduino-ide-extension/src/browser/arduino-ide-frontend-module.ts
  16. +13 −0 arduino-ide-extension/src/browser/arduino-preferences.ts
  17. +22 −2 arduino-ide-extension/src/browser/boards/boards-data-store.ts
  18. +44 −0 arduino-ide-extension/src/browser/contributions/board-selection.ts
  19. +56 −2 arduino-ide-extension/src/browser/contributions/check-for-ide-updates.ts
  20. +2 −2 arduino-ide-extension/src/browser/contributions/debug.ts
  21. +2 −1 arduino-ide-extension/src/browser/contributions/upload-sketch.ts
  22. +26 −11 arduino-ide-extension/src/browser/contributions/verify-sketch.ts
  23. +47 −0 arduino-ide-extension/src/browser/dialogs/ide-updater/ide-updater-dialog.tsx
  24. +107 −0 arduino-ide-extension/src/browser/dialogs/version-welcome-dialog.tsx
  25. +3 −0 arduino-ide-extension/src/browser/icons/link-open-icon.svg
  26. +32 −0 arduino-ide-extension/src/browser/style/ide-updater-dialog.css
  27. +1 −0 arduino-ide-extension/src/browser/style/index.css
  28. +7 −0 arduino-ide-extension/src/browser/style/version-welcome-dialog.css
  29. +241 −0 arduino-ide-extension/src/browser/theia/plugin-ext/tree-view-widget.tsx
  30. +4 −1 arduino-ide-extension/src/common/protocol/boards-service.ts
  31. +1 −0 arduino-ide-extension/src/common/protocol/ide-updater.ts
  32. +2 −1 arduino-ide-extension/src/common/protocol/sketches-service.ts
  33. +10 −1 arduino-ide-extension/src/node/arduino-ide-backend-module.ts
  34. +4 −0 arduino-ide-extension/src/node/boards-service-impl.ts
  35. +4 −4 arduino-ide-extension/src/node/cli-protocol/cc/arduino/cli/commands/v1/commands_grpc_pb.d.ts
  36. +25 −27 arduino-ide-extension/src/node/cli-protocol/cc/arduino/cli/commands/v1/commands_grpc_pb.js
  37. +4 −4 arduino-ide-extension/src/node/cli-protocol/cc/arduino/cli/commands/v1/commands_pb.d.ts
  38. +8 −8 arduino-ide-extension/src/node/cli-protocol/cc/arduino/cli/commands/v1/commands_pb.js
  39. +63 −0 arduino-ide-extension/src/node/cli-protocol/cc/arduino/cli/commands/v1/common_pb.d.ts
  40. +528 −2 arduino-ide-extension/src/node/cli-protocol/cc/arduino/cli/commands/v1/common_pb.js
  41. +10 −0 arduino-ide-extension/src/node/cli-protocol/cc/arduino/cli/commands/v1/debug_pb.d.ts
  42. +116 −4 arduino-ide-extension/src/node/cli-protocol/cc/arduino/cli/commands/v1/debug_pb.js
  43. +9 −54 arduino-ide-extension/src/node/cli-protocol/cc/arduino/cli/commands/v1/monitor_pb.d.ts
  44. +15 −379 arduino-ide-extension/src/node/cli-protocol/cc/arduino/cli/commands/v1/monitor_pb.js
  45. +15 −0 arduino-ide-extension/src/node/cli-protocol/cc/arduino/cli/commands/v1/upload_pb.d.ts
  46. +174 −6 arduino-ide-extension/src/node/cli-protocol/cc/arduino/cli/commands/v1/upload_pb.js
  47. +76 −39 arduino-ide-extension/src/node/core-service-impl.ts
  48. +4 −2 arduino-ide-extension/src/node/monitor-service.ts
  49. +37 −20 arduino-ide-extension/src/node/service-error.ts
  50. +64 −39 arduino-ide-extension/src/node/sketches-service-impl.ts
  51. +44 −0 arduino-ide-extension/src/node/theia/plugin-ext-vscode/scanner-vscode.ts
  52. +1 −1 arduino-ide-extension/src/test/node/core-service-impl.slow-test.ts
  53. +1 −0 docs/development.md
  54. +2 −2 electron-app/package.json
  55. +1 −1 electron-app/scripts/post-package.js
  56. +1 −1 electron-app/scripts/windowsCustomSign.js
  57. +5 −0 i18n/af.json
  58. +18 −13 i18n/ar.json
  59. +5 −0 i18n/az.json
  60. +6 −1 i18n/be.json
  61. +5 −0 i18n/bg.json
  62. +5 −0 i18n/ca_ES.json
  63. +13 −8 i18n/cs.json
  64. +5 −0 i18n/da.json
  65. +5 −0 i18n/de.json
  66. +5 −0 i18n/el.json
  67. +16 −0 i18n/en.json
  68. +11 −6 i18n/es.json
  69. +5 −0 i18n/eu.json
  70. +5 −0 i18n/fa.json
  71. +5 −0 i18n/fil.json
  72. +5 −0 i18n/fr.json
  73. +5 −0 i18n/he.json
  74. +5 −0 i18n/hu.json
  75. +5 −0 i18n/hy.json
  76. +5 −0 i18n/id.json
  77. +5 −0 i18n/it.json
  78. +5 −0 i18n/ja.json
  79. +6 −1 i18n/ko.json
  80. +5 −0 i18n/my_MM.json
  81. +5 −0 i18n/ne.json
  82. +5 −0 i18n/nl.json
  83. +5 −0 i18n/no.json
  84. +5 −0 i18n/pl.json
  85. +5 −0 i18n/pt.json
  86. +5 −0 i18n/ro.json
  87. +5 −0 i18n/ru.json
  88. +5 −0 i18n/si.json
  89. +557 −0 i18n/sk.json
  90. +5 −0 i18n/sr.json
  91. +5 −0 i18n/th.json
  92. +5 −0 i18n/tr.json
  93. +5 −0 i18n/uk.json
  94. +5 −0 i18n/vi.json
  95. +5 −0 i18n/zh-Hant.json
  96. +5 −0 i18n/zh.json
  97. +6 −1 i18n/zh_TW.json
  98. +1 −1 package.json
  99. +285 −51 yarn.lock
93 changes: 22 additions & 71 deletions .github/workflows/assets/linux.Dockerfile
Original file line number Diff line number Diff line change
@@ -1,43 +1,28 @@
# The Arduino IDE Linux build workflow job runs in this container.
# syntax=docker/dockerfile:1

FROM ubuntu:18.04

# See: https://unofficial-builds.nodejs.org/download/release/
ARG node_version="18.17.1"
# See: https://hub.docker.com/_/ubuntu/tags
FROM ubuntu:18.10

# This is required in order to use the Ubuntu package repositories for EOL Ubuntu versions:
# https://help.ubuntu.com/community/EOLUpgrades#Update_sources.list
RUN \
apt-get \
--yes \
update
sed \
--in-place \
--regexp-extended \
--expression='s/([a-z]{2}\.)?archive.ubuntu.com|security.ubuntu.com/old-releases.ubuntu.com/g' \
"/etc/apt/sources.list"

# This is required to get add-apt-repository
RUN \
apt-get \
--yes \
install \
"software-properties-common=0.96.24.32.22"
update

# Install Git
# The PPA is required to get a modern version of Git. The version in the Ubuntu 18.04 package repository is 2.17.1,
# while action/checkout@v3 requires 2.18 or higher.
RUN \
add-apt-repository \
--yes \
"ppa:git-core/ppa" && \
apt-get \
--yes \
update && \
\
apt-get \
--yes \
install \
"git" && \
\
apt-get \
--yes \
purge \
"software-properties-common"
"git"

# The repository path must be added to safe.directory, otherwise any Git operations on it would fail with a
# "dubious ownership" error. actions/checkout configures this, but it is not applied to containers.
@@ -51,62 +36,28 @@ ENV \

# Install Python
# The Python installed by actions/setup-python has dependency on a higher version of glibc than available in the
# ubuntu:18.04 container.
# container.
RUN \
apt-get \
--yes \
install \
"python3.8-minimal=3.8.0-3ubuntu1~18.04.2" && \
\
ln \
--symbolic \
--force \
"$(which python3.8)" \
"/usr/bin/python3"
"python3.7-minimal=3.7.3-2~18.10"

# Install Theia's package dependencies
# These are pre-installed in the GitHub Actions hosted runner machines.
RUN \
apt-get \
--yes \
install \
"libsecret-1-dev=0.18.6-1" \
"libx11-dev=2:1.6.4-3ubuntu0.4" \
"libsecret-1-dev=0.18.6-3" \
"libx11-dev=2:1.6.7-1" \
"libxkbfile-dev=1:1.0.9-2"

# Install Node.js
# It is necessary to use the "unofficial" linux-x64-glibc-217 build because the official Node.js 18.x is dynamically
# linked against glibc 2.28, while Ubuntu 18.04 has glibc 2.27.
ARG node_installation_path="/tmp/node-installation"
ARG artifact_name="node-v${node_version}-linux-x64-glibc-217"
RUN \
mkdir "$node_installation_path" && \
cd "$node_installation_path" && \
\
apt-get \
--yes \
install \
"wget=1.19.4-1ubuntu2.2" && \
\
archive_name="${artifact_name}.tar.xz" && \
wget \
"https://unofficial-builds.nodejs.org/download/release/v${node_version}/${archive_name}" && \
\
apt-get \
--yes \
purge \
"wget" && \
\
tar \
--file="$archive_name" \
--extract && \
rm "$archive_name"
ENV PATH="${PATH}:${node_installation_path}/${artifact_name}/bin"

# Install Yarn
# Yarn is pre-installed in the GitHub Actions hosted runner machines.
# Target python3 symlink to Python 3.7 installation. It would otherwise target version 3.6 due to the installation of
# the `python3` package as a transitive dependency.
RUN \
npm \
install \
--global \
"yarn@1.22.19"
ln \
--symbolic \
--force \
"$(which python3.7)" \
"/usr/bin/python3"
Loading