Use explicit filename source in config file artifact upload step of "Sync Labels" workflow #146
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" workflow 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. This repository's name does not have the problematic form, so the defect doesn't affect this project. However, this workflow is a standard "asset" which is maintained in a centralized repository for use in any project, so it is best to keep it in exact sync with the upstream copy.
per1234
added
type: enhancement
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.
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 thepathinput 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:Although this could be fixed by setting the "actions/upload-artifact" action's
include-hidden-filesinput totrue, it actually doesn't make sense to use a wildcard in thepathinput 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 thepathinput 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.This repository's name does not have the problematic form, so the defect doesn't affect this project. However, this workflow is a standard "asset" which is maintained in a centralized repository for use in any project, so it is best to keep it in exact sync with the upstream copy.