Sync "Sync Labels" workflow with upstream copy #23
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
…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. ``` This repository does not have a name that causes this problem, but this workflow is a copy of a "template" which is designed to be usable in any of Arduino's repositories, which might have problematic names, and so the defect had to be fixed in the upstream file. In order to facilitate its maintenance, it is best to keep this file in sync with the upstream. Alternatively, this defect could have been fixed by setting the "actions/upload-artifact" action's `include-hidden-files` input to `true`. However, 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.
GitHub Actions provides the capability for workflow authors to use the capabilities of the GitHub Actions ToolKit package directly in the `run` keys of workflows via "workflow commands". One such command is `set-output`, which allows data to be passed out of a workflow step as an output. It has been determined that this command has potential to be a security risk in some applications. For this reason, GitHub has deprecated the command and a warning of this is shown in the workflow run summary page of any workflow using it: > The `set-output` command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more > information see: > https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/ The identical capability is now provided in a safer form via the GitHub Actions "environment files" system. Migrating the use of the deprecated workflow commands to use the `GITHUB_OUTPUT` environment file instead fixes any potential vulnerabilities in the workflow, resolves the warnings, and avoids the eventual complete breakage of the workflows that would result from GitHub's planned removal of the `set-output` workflow command.
The "Sync Labels" workflow contains reference links to provide additional information to the users and maintainers. The targets of some of these links have moved since the time they were added. Although the user could still reach the intended content via a redirect, it is best not to rely on redirects continuing to work indefinitely. So the URLs are hereby updated to point directly to the target content.
`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, the templates are intended to
be applicable in public and private repositories both and so a small excess in permissions was chosen in order to use
the upstream templates unmodified.
per1234
added
type: imperfection
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.
The "Sync Labels" workflow is a copy of a "template" file that is hosted and maintained in a centralized repository dedicated to such reusable infrastructure assets:
https://github.com/arduino/tooling-project-assets/blob/main/workflow-templates/sync-labels.md
Several important fixes and enhancements have been made to the upstream workflow since the time the workflow was installed in this repository. The upstream changes are hereby pulled into this repository's workflow.