The "Sync Labels" workflow was originally developed with Arduino firmware repositories in mind. Those projects don't
have a lot of existing infrastructure and, since they are intended to be very approachable, the impact of adding
additional non-firmware files or folders (especially in the root) must be carefully considered.
In that context, a self-contained workflow is desirable. However, the situation is different in the inherently more
complex and infrastructure rich tooling projects, which are typically consumed only as a binary by users.
For this reason, an alternative standardized version of the "Sync Labels" workflow was produced, which utilizes npm to
manage its tool dependencies.
The code dependencies of this project and the code infrastructure are already managed via npm, which means the switch to
this superior version of the workflow can be made without the need to add any additional infrastructure.
This provides some significant benefits:
- Controlled updates via Dependabot PRs instead of being subject to immediate breakage resulting from a new tool release
- Enables automated vulnerability alerts
This is especially important for the github-label-sync tool, since it is making irreversible writes to the GitHub
repository.
In addition to helping others use Task in their GitHub Actions workflows, this project uses Task for its own development.
Most of the repository's GitHub Actions workflows use the approach of executing a task. This approach allows maintaining
a single set of commands that can easily be used locally by contributors in addition to their use by the CI system.
The "Check npm" workflow was an exception to this pattern, using commands directly coded into the workflow file. This
meant the contributor would need to study the workflow and run the multiple equivalent complex commands locally if they
wanted to validate changes to the npm configuration in advance of pushing, or troubleshoot a problem flagged by the
workflow.
We already have a Task-based version of the workflow and accompanying tasks, which are generally preferred for Arduino
tooling projects and especially appropriate for this specific project which is devoted to Task:
https://github.com/arduino/tooling-project-assets/blob/main/workflow-templates/check-npm-task.md
Those standardized assets are hereby used in this repository, moving the commands from the workflow to an npm:validate
task and switching the workflow to using that task.
In addition to helping others use Task in their GitHub Actions workflows, this project uses Task for its own development.
Most of the repository's GitHub Actions workflows use the approach of executing a task. This approach allows maintaining
a single set of commands that can easily be used locally by contributors in addition to their use by the CI system.
The "Check TypeScript Configuration" workflow was an exception to this pattern, using commands directly coded into the
workflow file. This meant the contributor would need to study the workflow and run the multiple equivalent complex
commands locally if they wanted to validate changes to the TypeScript configuration in advance of pushing, or
troubleshoot a problem flagged by the workflow.
These commands are hereby moved to a ts:validate task and the workflow switched to using that task.
This is intended to be a straight across transfer of the existing commands (or their equivalents) to the task.
A task and GitHub Actions workflow are provided here for checking the license types of npm-managed project dependencies.
On every push and pull request that affects relevant files, the CI workflow will check:
- If the dependency licenses cache is up to date
- If any of the project's dependencies have an unapproved license type.
Approval can be based on:
- Universally allowed license type
- Individual dependency
Previously, due to the lack of a release, the only option was to use the default branch name for the action ref. Using
release versions provides a more stable experience for the ordinary users of these actions and also eases ongoing
development work on the actions.
Use of the major version ref will cause the workflow to benefit from ongoing development to the action at each patch or
minor release up until such time as a new major release is made, at which time the user will be given the opportunity
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: arduino/setup-task@v2`).
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
History shows that the previous description "latest stable version of Task" is not likely to be accurate over time.
Better to just be honest about what the action does.
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.
This allows the node_modules to be removed from the repository, as is already done in the `arduino/setup-arduino-cli`,
`arduino/arduino-lint-action`, and `arduino/create-changelog` actions.
Whenever one of the recognized license file names are modified in the repository, the workflow runs to check whether the
license can be recognized and whether it is of the expected type.
