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.
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.
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.
- 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
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
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>
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.
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>
