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