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>
* Fix corruption of incoming UTF-8-encoded serial data
* Make TextDecoder() readonly because it can be
Co-authored-by: z3bra <111462146+z3bra5hax@users.noreply.github.com>
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.
