Sync infrastructure assets from upstream "templates" #59
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… repositories Read permissions are required in the "contents" scope in order to checkout private repositories. Even though those permissions are not required in this project where the workflow is installed in a public repository, this is a copy of a "template" that is intended to be applicable to any Arduino Tooling project. A small excess in permissions in the template was chosen instead of the alternative of having to maintain separate variants of each workflow for use in public or private repos.
`GITHUB_TOKEN` is an access token that is automatically generated and made accessible for use in GitHub Actions workflow
runs. The global default permissions of this token for workflow runs in a trusted context (i.e., not triggered by a
`pull_request` event from a fork) are set in the GiHub enterprise/organization/repository's administrative settings,
giving it either read-only or write permissions in all scopes.
In the case of a read-only default configuration, any workflow operations that require write permissions would fail with
an error like:
> 403: Resource not accessible by integration
In the case of a write default configuration, workflows have unnecessary permissions, which violates the security
principle of least privilege.
For this reason, GitHub Actions now allows fine grained control at a per-workflow or per-workflow job scope of the
permissions provided to the token. This is done using the `permissions` workflow key, which is used here to configure
the workflows for only the permissions require by each individual job.
I chose to always configure permissions at the job level even though in some cases the same permissions configuration
could be used for all jobs in a workflow. Even if functionally equivalent, I think it is semantically more appropriate
to always set the permissions at the job scope since the intention is to make the most granular possible permissions
configuration. Hopefully this approach will increase the likelihood that appropriate permissions configurations will be
made in any additional jobs that are added to the workflows in the future.
The automatic permissions downgrade from write to read for workflow runs in an untrusted context (e.g., triggered by a
`pull_request` event from a fork) is unaffected by this change.
Even when all permissions are withheld (`permissions: {}`), the token still provides the authenticated API request rate
limiting allowance (authenticating API requests to avoid rate limiting is a one of the uses of the token in these
workflows).
Read permissions are required in the "contents" scope in order to checkout private repositories. Even though those
permissions are not required when the workflows are installed in this public repository, some of these workflows are
copies of "templates" which are intended to be applicable in public and private repositories both. A small excess in
permissions was chosen instead of the alternative of having to maintain separate variants of each workflow template for
use in public or private repos.
The codespell tool is used to detect commonly misspelled words in the files of the project. Infrastructure is provided for running the tool locally and a GitHub Actions workflow also runs it automatically when files are changed and periodically. Previously the infrastructure was very outdated. It is hereby updated to the state of the art: - codespell dependency managed by Poetry and dependabot - Task-based to allow contributors to run the same check as done by the CI system via a standardized interface - Use standard codespell configuration file - Use codespell's official GitHub Actions instead of Arduino's action (deprecated in favor of the official action)
The project infrastructure validates the package.json npm configuration files against their JSON schema. Previously, in order to provide validation coverage for all package.json files in any locations in the repository, a "globstar" was used to cause the validator to recursively search the entire file tree under the repository. That approach is problematic because the repository contains externally maintained files (e.g., the npm packages under the node_modules folder). Searching and validating these files is inefficient at best and the cause of spurious failures at worst. This is avoided by targeting the search. Support for a repository maintainer to configure any number of specific locations of npm-managed projects in the "Check npm" workflow has been added, so this system is used to target the validations. When the `npm:validate` task is ran by a contributor on their local clone, it defaults to the root of the repository, but the path can be configured by setting the PROJECT_PATH taskfile variable via an argument to the task invocation command.
per1234
added
type: enhancement
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #59 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 2 2
Lines 732 732
=========================================
Hits 732 732 ☔ View full report in Codecov by Sentry. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Arduino tooling projects use a standardized infrastructure. A centralized collection of reusable infrastructure assets is maintained in a dedicated repository:
https://github.com/arduino/tooling-project-assets
Since the time this project's infrastructure was installed, some advancements have been made in the upstream "template" assets. The project's infrastructure is hereby brought up to date with the state of the art upstream assets.