Closed JaleelB closed 4 months ago
rimrul
commented
1 year ago This issue was previously addressed and resolved in version 2.1.4, as demonstrated in the following pull request: Fix windows cache path by aigiaoy • Pull Request #670.
The error message does not look like #632/#670, but rather #1073.
When using version 2.1.4, the cache is created successfully, as shown in the output below:
Because that uses BSD tar. (#1039)
JaleelB
commented
1 year ago This issue was previously addressed and resolved in version 2.1.4, as demonstrated in the following pull request: Fix windows cache path by aigiaoy • Pull Request #670.
The error message does not look like #632/#670, but rather #1073.
When using version 2.1.4, the cache is created successfully, as shown in the output below:
Because that uses BSD tar. (#1039)
Ok, thanks🙏
DooDeeDee
commented
12 months ago Description:
Version 3 of the cache action breaks caching for Windows self-hosted runners, specifically when running on a self-hosted runner utilizing the Windows operating system. The issue stems from the action's inability to create the cache due to path-related problems. This problem occurs during the post-cache cleanup process, as evidenced by the error message provided below:
This issue was previously addressed and resolved in version 2.1.4, as demonstrated in the following pull request: Fix windows cache path by aigiaoy • Pull Request #670. When using version 2.1.4, the cache is created successfully, as shown in the output below:
Upon closely comparing the fixed version (2.1.4) with the latest (v3), I observed that some conditional logic was added to the resolvePaths function in v3. This newly introduced conditional logic seems to have inadvertently caused the path-related issue to resurface for Windows runners. Specifically, the changes made in v3 appear to have altered how relative paths are resolved and subsequently pushed to the paths array, leading to an inability to handle paths correctly on Windows self-hosted runners.
Unfortunately, pinning the workflow to version 2.1.4 is not a viable long-term solution, as that version of the action relies on the save-output/save-state functionality, which was announced to be deprecated in June. This means that sticking with version 2.1.4 would leave me with an unsupported action in just a few months.
In light of this, I request that the maintainers of the actions/cache action update version 3 incorporate a similar logic to version 2.1.4. This would involve reevaluating the changes made to the Resolve Paths function, identifying the specific alteration that has led to the path-related issue, and adjusting the implementation accordingly to resolve the problem and prevent the cache from breaking on Windows self-hosted runners.
As we wait for a fix or an updated action version, I would greatly appreciate any suggestions for temporary workarounds to help reduce the issue. This could include alternative methods for handling paths on Windows runners or any known ways to bypass the problematic portion of the code.
``
cpajonk
commented
11 months ago Another major issue is that someone sits in front of a computer and takes a photo of the screen instead of doing a normal screenshot.
github-actions[bot]
commented
4 months ago This issue is stale because it has been open for 200 days with no activity. Leave a comment to avoid closing this issue in 5 days.
Description:
Version 3 of the cache action breaks caching for Windows self-hosted runners, specifically when running on a self-hosted runner utilizing the Windows operating system. The issue stems from the action's inability to create the cache due to path-related problems. This problem occurs during the post-cache cleanup process, as evidenced by the error message provided below:
This issue was previously addressed and resolved in version 2.1.4, as demonstrated in the following pull request: Fix windows cache path by aigiaoy • Pull Request #670. When using version 2.1.4, the cache is created successfully, as shown in the output below:
Upon closely comparing the fixed version (2.1.4) with the latest (v3), I observed that some conditional logic was added to the resolvePaths function in v3. This newly introduced conditional logic seems to have inadvertently caused the path-related issue to resurface for Windows runners. Specifically, the changes made in v3 appear to have altered how relative paths are resolved and subsequently pushed to the paths array, leading to an inability to handle paths correctly on Windows self-hosted runners.
Unfortunately, pinning the workflow to version 2.1.4 is not a viable long-term solution, as that version of the action relies on the save-output/save-state functionality, which was announced to be deprecated in June. This means that sticking with version 2.1.4 would leave me with an unsupported action in just a few months.
In light of this, I request that the maintainers of the actions/cache action update version 3 incorporate a similar logic to version 2.1.4. This would involve reevaluating the changes made to the resolvePaths function, identifying the specific alteration that has led to the path-related issue, and adjusting the implementation accordingly to resolve the problem and prevent the cache from breaking on Windows self-hosted runners.
As we wait for a fix or an updated action version, I would greatly appreciate any suggestions for temporary workarounds to help reduce the issue. This could include alternative methods for handling paths on Windows runners or any known ways to bypass the problematic portion of the code.