The test runner CI workflow was using Node.js 12.x, which reaches EOL 2022-04-30.
Other workflows did not specify a Node.js version, meaning they used whatever was installed on the GitHub Actions runner.
It will be best to define a specific version series for use and use that throughout the infrastructure and development.
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.
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" assets and their installation in this repository.
The use of the `error` workflow command will cause the important error message output to be surfaced prominently in the
workflow run summary and log. The workflow run logs can be somewhat labyrinthine to those who don't work with them
regularly, so finding the previous output to determine what caused the failure might have been challenging.
Even if it works as intended, it is not clear what the effect is of the escaped quote at the end of the environment
variables in the shell commands used to check the license detection results. Wrapping the variable names in braces
ensures they are as expected and also makes the working of the code clear.
Placement of this information at the top of the file, where it is easy to find and edit, facilitates updates to the
workflows as the tool versions used for project development are bumped periodically.
The paths filter is used to make GitHub Actions workflows more efficient and contributor friendly by preventing pointless
workflow runs from happening when only irrelevant files were modified. However, careful consideration must be given to
which files are relevant. In some cases, this can lead to a very lengthy list of path patterns. These can be compressed
down through the use of advanced patterns.
There are two file extensions in common use for YAML files: `.yaml` and `.yml`. Although this project uses `.yml`
exclusively for YAML files, these are standardized workflows which might be applied to projects that have established the
use of the other extension. It will be most flexible if it supports both.
This useful action is an integral part of the CI system. Now that it has a dedicated repository and a new name, the CI
workflows must be updated to use the latest release version of the action.
The default behavior is to cancel all the other matrix jobs if one fails. However, it can often be valuable to see what
the results are of the other jobs. In this case where the matrix is operating systems, it can be useful to see whether
the problem is specific to one OS, or if it affects all.
The `workflow_dispatch` event trigger allows the workflow to be run manually via the GitHub web interface. This can be
useful to trigger the workflow run in cases where the standard triggers won't, such as testing how external changes
(e.g., actions used in the workflow) affected it.
The `repository_dispatch` event serves a similar purpose, except triggered via the GitHub API.
Node.js 12 is the newest version available for the JavaScript GitHub Actions actions, and is the one in use, as specified
in action.yml's `runs.using` key. So it is best to use the same when running the tests in the CI workflow.
Use of the major version ref will cause the workflow to use stable release versions of the utility actions while
automatically benefiting from ongoing development to those actions 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 updating the major ref
(e.g., `uses: actions/checkout@v2` -> `uses: actions/checkout@v3`).
"setup-taskflile" was an artifact of the project's previous home in the `arduino/actions` repo, which hosts multiple
actions. In that case, it made some sense to have a single monolithic workflow for each project, named after the project.
Now that the action has a dedicated repository. It is more useful to name the workflows according to their intended
purpose.
At the time the "Check TypeScript Configuration" workflow was created, the eslint proposal was still pending, so only
tsconfig.json was validated in the initial implementation of the workflow.
Now that the project contains two tsconfig files and the infrastructure is in place to easily validate any number of
these files, it might as well be used to the fullest extent.
GitHub Actions has the annoying behavior of converting LF to CRLF when checking out on the Windows runner. This caused
the formatting check to fail because Prettier now mandates Unix-style EOL.
Change project name to "arduino/setup-task"
The Task documentation consistently refers to the tool as "Task". Taskfile is the term used for Task's configuration file.
This action is setting up the Task tool, not setting up the Task configuration file, so "arduino/setup-task" is more
appropriate than "arduino/setup-taskfile".
On every push and pull request that affects relevant files, and periodically, check the repository's Markdown files for
problems:
- Use markdownlint to check for common problems and formatting.
- Use markdown-link-check to check for broken links.
Arduino's Markdown style is defined by the `.markdownlint.yml` file.
In the event the repository contains externally maintained Markdown files, markdownlint can be configured to ignore them
via a `.markdownlintignore` file:
https://github.com/igorshubovych/markdownlint-cli#ignoring-files
markdown-link-check is configured via the `.markdown-link-check.json` file:
https://github.com/tcort/markdown-link-check#config-file-format
On every push and pull request that affects relevant files, and periodically:
- Validate package.json against its JSON schema.
- Check for forgotten manifest updates.
Building will now be done in the same commit as the changes to the source code, so doing it in the integration test
workflow is pointless, only making the CI slower and the maintenance burden greater.
In order to allow beta testing, it is necessary to package the action after every change to the code. This is an easy
step to forget, so an automated check is necessary.
On every push, pull request, and periodically, use the codespell-project/actions-codespell action to check for commonly
misspelled words.
In the event of a false positive, the problematic word should be added, in all lowercase, to the ignore-words-list field
of ./.codespellrc. Regardless of the case of the word in the false positive, it must be in all lowercase in the ignore
list. The ignore list is comma-separated with no spaces.
