[pull] main from arduino:main #43
Merged
Conversation
This file contains hidden or 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
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
Previously, the command was erroneously split at the first parenthesis. This resulted in the introduction of spaces between the two parentheses, which caused the syntax to be interpreted as a command substitution operator instead of the intended arithmetic expansion operator. This caused the command to fail: ``` /home/runner/work/_temp/2470dde2-826c-4a00-8268-b8d111566dc2.sh: line 46: syntax error near unexpected token `/' ```
Correct syntax of shell code in "Check Certificates" workflow
The "Check npm" template provides actions and a GitHub Actions workflow used to check for problems with a project's npm configuration files. In addition to the `package.json` file previously used, we are now using an `.npmrc` configuration file. It will be useful to have some validation for this file. npm provides a `config fix` command which automatically fixes any problems that are detected with the npm configuration. In addition to using it for that purpose, it can also serve as a check by running the command via the GitHub Actions workflow, then checking for any diff. Beyond the automated fixes, it is hoped that the parsing of the configuration that npm must perform to check for any needed fixes provides a basic validation of the configuration. Unfortunately npm's parser is extremely lenient, so the validation is not at all comprehensive. However, it is probably better than nothing, simple to implement, and no alternatives were found.
Check/fix problems with npm configuration
Prettier uses filename pattern matching to identify the programming language of files (and from this determines which files to format, and how to format those files). This is based on data from the "Linguist" project. That data was used as a reference for configuring the paths filter of the "Check Prettier Formatting" workflow, which ensures that the workflow will run whenever relevant files are modified. Documenting that reference via a comment in the workflow will facilitate the maintenance of the paths filter.
Add reference link comment for Prettier filename matching patterns
Previously, a "block scalar" was used in the workflow. This is useful in the case of a multi-line string. However, this string is only a single line. Although it would be useful to break the command up into multiple lines via the use of the line continuation operators, this is not possible due to a quirk of the action. So the use of the "block scalar" is not really beneficial in this case. Furthermore, the use of the "block scalar" might encourage the maintainer to try to split the command into multiple lines as is common practice for complex shell commands in the infrastructure, leading to wasted time.
Simplify workflow code
…Sync Labels" workflows Starting from version 3.2.0 of the "actions/upload-artifact" action, "hidden" files are not uploaded by default. The action considers a file "hidden" if any component of the path starts with `.`. The "download" job of the "Sync Labels" workflow downloads each of the shared label configuration files from and uploads them to GitHub Actions workflow artifacts for use by the subsequent job. Since the names of the configuration files don't start with `.` and they aren't located in a subfolder that starts with `.`, we would not expect that this job could be impacted by the new hidden file handling behavior. However, it was impacted after all, under certain conditions. Previously, wildcard patterns were used in the `path` input of the job's "actions/upload-artifact" action step. It turns out that in the case of wildcards, the entire absolute path to the file is considered in the determination of whether it is "hidden". The "workspace" in which the workflow's steps are performed is under a path that includes the repository name. So if the repository name starts with a `.` (e.g., `.github`), then the "actions/upload-artifact" action step failed spuriously: ``` Run actions/upload-artifact@v3 Error: No files were found with the provided path: *.yaml *.yml. No artifacts will be uploaded. ``` Although this could be fixed by setting the "actions/upload-artifact" action's `include-hidden-files` input to `true`, it actually doesn't make sense to use a wildcard in the `path` input when the name of the single file is already available (the wildcard approach is a vestigial remnant of a previous version of the workflow that downloaded all configuration files in a single job, before it was changed to using a job matrix). By changing the `path` input value to the file's explicit relative path, it is ensured that the file will never be treated as "hidden", regardless of the repository name.
Use explicit filename source in config file artifact upload step of "Sync Labels" workflow
The project's Python package dependencies are managed using the Poetry tool. By default, Poetry is configured in "package mode", which is intended for use with projects that are a Python package. When Poetry is used in a project like this that is a standalone script, this configuration is inappropriate and has the following effects: * `poetry install` command installs the project as a Python package in addition to the dependencies. * `name`, `version`, `description`, and `authors` fields of the pyproject.toml file are required. Installing the project as a package is completely inappropriate if the project is not a package, and may cause the command to fail with a cryptic error. This can be avoided by passing the `--no-root` flag to the `install` command, but that increases the usage complexity and chance for user error. Although metadata fields under the `tool.poetry` section of the pyproject.toml configuration file are important for a package, in a non-package project there are better ways to provide that information. Since Git tags are used for versioning, the presence of a `version` field is especially harmful since it means duplication of information and extra work for the project maintainer (and likelihood the metadata will not be kept updated). This "package mode" can be disabled via the pyproject.toml configuration file, which causes Poetry to operate purely in the sole capacity in which it is used by this project: to manage dependencies.
Disable Poetry "package mode"
The "ajv-cli" command line tool is used for validating data files against their JSON schema. The tool is used to validate the project's npm package.json configuration file. In general, it is preferable (and for some schemas even mandatory) to use the latest version of ajv-cli. However, support for the "Draft-04" schema specification was dropped in ajv-cli version 4.0.0. So when working with JSON schemas that specify that draft, it is necessary to use ajv-cli 3.3.0, the last compatible version. Previously, the package.json schema specified the "Draft-04" specification. For this reason, the `npm:validate` task was configured to use ajv-cli@3.3.0. The package.json schema has now been updated to use the "Draft-07" schema specification. So the code for using ajv-cli@3.3.0 is removed from the task, and it will now instead use the standard project level version of ajv-cli.
Use project version of ajv-cli in npm:validate task
The "Task" task runner tool is used to perform common development operations for the project. Tasks may call other tasks. Under certain conditions (most commonly when running a convenience "umbrella" which calls all tasks of a general type), this can result in the same task being called redundantly, which is inefficient. Worse, since task calls specified via the `deps` mapping of a task definition are executed concurrently, the multiple executions can conflict with each other and cause problems such as a spurious failure. This can be avoided by configuring tasks which may be called multiple times, and for which it never makes sense to execute multiple times with the same conditions, so that all but the first call will be ignored.
Configure task dependencies to avoid redundant execution
The "Poetry" tool is used to manage the project's Python package dependencies. Dependencies might be classified into distinct categories. The most basic classification would be: - Application dependencies: used by the project's applications - Development dependencies: tools used in the development and maintenance of the project, but not by the application By default, Poetry installs all non-optional dependencies. This can be inefficient in a case where a specific operation is being performed, since a given operation might only require the dependencies from one category and so the installation of dependencies from the other is pointless for that operation. For this reason, Poetry allows the user to organize dependencies into arbitrary "groups", and to specify which groups should be installed. The Python package installation task is hereby updated to allow dependency groups to be specified, and the calls to that task updated to specify the groups they require.
Only install Python package dependencies from relevant group
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.3)
Can you help keep this open source service alive? 💖 Please sponsor : )