From 75d057460acd42d5a918df9e031810fbdcefd994 Mon Sep 17 00:00:00 2001 From: per1234 Date: Sat, 1 Feb 2025 11:12:41 -0800 Subject: [PATCH 1/4] Use explicit filename source in config file artifact upload step of "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/workflows/sync-labels.yml | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/.github/workflows/sync-labels.yml b/.github/workflows/sync-labels.yml index 514f29a..3c34186 100644 --- a/.github/workflows/sync-labels.yml +++ b/.github/workflows/sync-labels.yml @@ -72,9 +72,7 @@ jobs: - name: Pass configuration files to next job via workflow artifact uses: actions/upload-artifact@v4 with: - path: | - *.yaml - *.yml + path: ${{ matrix.filename }} if-no-files-found: error name: ${{ env.CONFIGURATIONS_ARTIFACT_PREFIX }}${{ matrix.filename }} From cb56af29ccd1044255aadff20cdfb961e9ce5bce Mon Sep 17 00:00:00 2001 From: per1234 Date: Sat, 1 Feb 2025 11:12:50 -0800 Subject: [PATCH 2/4] Migrate "Sync Labels" workflow from deprecated `set-output` commands 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. --- .github/workflows/sync-labels.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/sync-labels.yml b/.github/workflows/sync-labels.yml index 3c34186..cbe9479 100644 --- a/.github/workflows/sync-labels.yml +++ b/.github/workflows/sync-labels.yml @@ -100,7 +100,7 @@ jobs: run: | # Use of this flag in the github-label-sync command will cause it to only check the validity of the # configuration. - echo "::set-output name=flag::--dry-run" + echo "flag=--dry-run" >> $GITHUB_OUTPUT - name: Checkout repository uses: actions/checkout@v4 From a870850c92fa4546d988d577a2f9210b09c33d93 Mon Sep 17 00:00:00 2001 From: per1234 Date: Sat, 1 Feb 2025 11:13:00 -0800 Subject: [PATCH 3/4] Update redirecting URLs in reference links of workflow 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/workflows/sync-labels.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.github/workflows/sync-labels.yml b/.github/workflows/sync-labels.yml index cbe9479..8772b7a 100644 --- a/.github/workflows/sync-labels.yml +++ b/.github/workflows/sync-labels.yml @@ -1,7 +1,7 @@ # Source: https://github.com/arduino/tooling-project-assets/blob/main/workflow-templates/sync-labels.md name: Sync Labels -# See: https://docs.github.com/en/actions/reference/events-that-trigger-workflows +# See: https://docs.github.com/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows on: push: paths: @@ -83,7 +83,7 @@ jobs: steps: - name: Set environment variables run: | - # See: https://docs.github.com/en/actions/reference/workflow-commands-for-github-actions#setting-an-environment-variable + # See: https://docs.github.com/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions#setting-an-environment-variable echo "MERGED_CONFIGURATION_PATH=${{ runner.temp }}/labels.yml" >> "$GITHUB_ENV" - name: Determine whether to dry run From dc0e4b975501f29fe87507ec32e6d76a646d6a7d Mon Sep 17 00:00:00 2001 From: per1234 Date: Sat, 1 Feb 2025 11:13:13 -0800 Subject: [PATCH 4/4] Configure permissions of `GITHUB_TOKEN` in workflow `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. --- .github/workflows/sync-labels.yml | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/.github/workflows/sync-labels.yml b/.github/workflows/sync-labels.yml index 8772b7a..1556976 100644 --- a/.github/workflows/sync-labels.yml +++ b/.github/workflows/sync-labels.yml @@ -24,6 +24,8 @@ env: jobs: check: runs-on: ubuntu-latest + permissions: + contents: read steps: - name: Checkout repository @@ -55,6 +57,7 @@ jobs: download: needs: check runs-on: ubuntu-latest + permissions: {} strategy: matrix: @@ -79,6 +82,9 @@ jobs: sync: needs: download runs-on: ubuntu-latest + permissions: + contents: read + issues: write steps: - name: Set environment variables