Support cache-dependency-paths outside the current directory

Description:

I'm building a composite Action which uses actions/setup-python internally. When specifying the requirements.txt from the action setting up Python fails, though I thiiink I'm passing the right values.

Here's what I've got:

    - name: Set up Python
      uses: actions/setup-python@v3
      with:
        python-version: '3.10'
        cache: pip
        cache-dependency-path: ${{ github.action_path }}/requirements.txt

Here's the error I get:

No file in /home/runner/work/sr2022-comp/sr2022-comp matched to [/home/runner/work/_actions/PeterJCLaw/srcomp-validate-action/bd809ff12b77607cc2f0ebbd035d6f0a5c8d32fc/requirements.txt], make sure you have checked out the target repository

sr2022-comp is the repo I'm using to test the action, srcomp-validate-action is the action.

My specific use-case only has a couple of dependencies so #351 would likely work as a fix, though I can imagine that a more complex scenario would want this to work.

Platform: Ubuntu

I'm currently working around this by coping the requirements file into a temporary directory within the working directory and then referencing that, instead of the original. This doesn't feel like a great solution though as it ends up polluting the target repo's working copy.

@PeterJCLaw

Hello @PeterJCLaw. Thank you for your report. Could you please provide a public repository to reproduce the issue ?

@PeterJCLaw

Hello @PeterJCLaw. Actually, I think the root cause of the issue in the toolkit/glob package. The hashFiles function tries to compare if the passed directory matches with GITHUB_WORKSPACE. The composite action's directory and checkout project's directory don't match, that is why if does hash the file and the actions setup-python throws an error.

Thanks for your replies.
For completeness the repos in question are:

I've raised actions/toolkit#1035 for the underlying issue.

@PeterJCLaw

Hello @PeterJCLaw. For now I'm going to close the pull request because the root cause of the issue comes from the toolkit repository. If you have any concerns feel free to ping us.

ci: attempt to use pip cache to speedup

@dmitry-shibanov

@dmitry-shibanov would you be open to reopening this issue? It looks like hashFiles has a new parameter now which allows callers to specify the workspace directory (actions/toolkit#1318), which I think would help here?

@PeterJCLaw

Hello @PeterJCLaw. In this case I'm coming to reopen the issue to investigate it one more time.

edit: Sorry for edit in the first glance I thought it was a pull request.

@dmitry-shibanov

@dmitry-shibanov we also got hit by this one, any news whether this can be addressed now, that there is a new parameter in toolkit available?

@dekimsey

Hello @dekimsey, Thank you for your feedback and for providing additional context regarding the new changes in setup-python v5.

We understand the concern around the inability to use absolute paths with composite actions. To clarify, the symbolic link approach was suggested as a temporary solution to allow the setup-python action to reference files (like requirements.txt) located outside the default path scope.

We completely agree with your point about the potential side effects of modifying the workspace, particularly with shared or pre-existing directories. We’ll focus on more robust approaches, such as using a temporary directory or scratch space, when implementing this feature.

Thanks again for your valuable input! Please let us know if you have any further suggestions.

To work around this limitation when using absolute paths, we create a symbolic link to requirements.txt from the composite action's directory.

Would this not overwrite or otherwise modify the workspace just to execute the setup-python action?

You can partially hedge this concern by naming your symlink something that wouldn't affect the "parent" repo at all. For example:

    - name: Create symlink for requirements.txt
-     run: ln -s ${{ github.action_path }}/requirements.txt
+     run: ln -s ${{ github.action_path }}/requirements.txt foobarbazboom.txt
      shell: bash

    - name: Set up Python
      uses: actions/setup-python
      with:
        python-version: '3.11'
        cache: 'pip'
+       cache-dependency-path: foobarbazboom.txt

And if desired, clean it up afterwards with a simple rm.

What was the reasoning behind the design to not allow for using the requirements.txt file within the action's repository? Did this come from a GitHub Actions file context scoping issue or som other factor?

Hello Everyone, we’ve raised #1128 to address the above request. Please validate it against the requirement that caching should work when the project is not located at the root of the repository, and confirm if we can proceed further.
Feel free to reach out if you have any questions or need additional clarification.

Hello Everyone, The issue regarding cache not working when the project is not located at the root of the repository has been addressed and resolved through PR #1128, which has now been merged into main.

With this update, caching behavior should now work when the project is not in the root of the repository hence closing this issue. Please feel free reach us in case of any concerns / clarifications needed.

@aparnajyothi-y apologies for not replying sooner, I think I missed the previous request for validation. Unfortunately I think there are some issues with #1128 which make it unsuitable as a fix for this -- mainly that is quite likely to result in accidental pollution of the end-user's working checkout, but also that it doesn't solve this issue for cases not involving a composite action. (Have posted there with more details, but happy to open a separate issue if that's preferred).

Edit: I would encourage that any fix which includes placement of the file within the workspace make use of https://nodejs.org/api/fs.html#fs_fs_mkdtemp_prefix_options_callback, as that will enable creation of a non-conflicting directory to place the file in.

@PeterJCLaw

Hello @PeterJCLaw, Using fs.mkdtemp() to copy a file into /tmp doesn’t help if a matching file exists in the workspace root, because tools like setup-python resolve cache-dependency-path globs from GITHUB_WORKSPACE. So, the file in /tmp is ignored unless explicitly referenced in the workflow YAML.

To address this, we default overwrite to false, preventing unintended overwrites of user files. If a file with the same name already exists in the workspace, we skip copying and display a clear warning. This avoids accidental pollution of the user’s repository while still allowing advanced users to opt in via overwrite: true when needed.

This approach ensures safety by default and flexibility when intentional overrides are required.
We’ve captured this logic in this PR #1149. Please validate from your end and let us know in cases of any concerns/clarifications are required

Hello @PeterJCLaw, Using fs.mkdtemp() to copy a file into /tmp doesn’t help if a matching file exists in the workspace root, because tools like setup-python resolve cache-dependency-path globs from GITHUB_WORKSPACE. So, the file in /tmp is ignored unless explicitly referenced in the workflow YAML.

@aparnajyothi-y thanks for picking this up. Apologies if there was a lack of clarity on my part -- I was expecting that the use of fs.mkdtemp() would be to create a directory within the workspace, by passing in a suitable prefix.

This would ensure that the action always work without additional effort from callers. This is important since the immediate caller is (probably) not the one in control of the workspace -- they're merely providing an action for someone else to use. I don't think it's a great idea to force the author of the intermediate action (i.e: caller of setup-python) to have to decide whether or not to overwrite something in their caller's workspace -- since they don't know what's there.

This approach does accept a small risk that the calling code might accidentally conflict with the directory created, however IMO this is vanishingly small and a worthwhile trade-off as a workaround until actions/toolkit#1035 is addressed.

In case it's useful to see how this would work, while not implemented in JavaScript, this is the same as the workaround logic I've used in the action I authored which triggered this report. Here's the lines in question: https://github.com/PeterJCLaw/srcomp-validate-action/blob/15580edf2a3caf3c68d11ca159bb4d56a807cf49/action.yml#L12-L14

@PeterJCLaw

Hello @PeterJCLaw, Thanks for validating and sharing the details. As confirmed, dependency files outside $GITHUB_WORKSPACE (e.g., those written to /tmp using fs.mkdtemp()) are not picked up by setup-python's cache-dependency-path logic due to how glob resolution works.
For now, we'll proceed with the current PR that copies the dependency file into the workspace by default (with overwrite: false) to ensure cache correctness and prevent unintended file pollution.
We agree that using temp directories would be ideal once upstream support (e.g., toolkit#1035) is in place. We'll revisit and enhance the implementation when that becomes available. Let us know if you have any further suggestions!

@aparnajyothi-y thanks for the reply, however I think there is a misunderstanding here and I wanted to make a few things really clear:

I do not believe that the current fix (with or without PR #1149) addresses the issue that I originally raised -- I would need to continue working around this issue (as I already have) regardless of whether these changes are released.
I believe that the fix in PR #1128 as it stands is a net negative change due to the issue I raised around accidental overwriting, so I would discourage releasing actions/setup-python in the current state
The changes in PR #1149 are neither necessary nor sufficient to address the core issue here, yet does introduce additional complexity, so I would discourage merging that PR or releasing actions/setup-python with that merged
My core concern with the approach the fixes take is that they are unsafe by default and fail quietly. In contrast the reported behaviour is at least a loud error, enabling the user to (fairly) easily diagnose and resolve the issue. With these changes, the failure mode is quieter and push additional burden onto users to work around something that this action can address directly.
I am aware that a directory (temporary or otherwise) outside the workspace would not be picked up. Using such a directory is not what I am proposing.

What I am proposing is a solution like this:

create a temporary directory (guaranteed to be uniquely named) within the workspace -- my reading of the docs suggests that fs.mkdtemp supports this by passing the prefix argument
copy or link the necessary files into that directory

Is there a reason that this proposed solution would not work? What am I missing here?

Hi everyone, Following up on this discussion and the recent implementation in PR #1128:

After further review and discussion, we’ve decided to revert PR #1128. In that implementation, a file was copied from the composite action into the main workspace at a repository level. This was initially intended to support composite actions in setup-python and provided valuable insight into how such scenarios could be addressed.

Moving forward, we’ll be implementing this capability at the toolkit level, as tracked in actions/toolkit#1035
. This will allow us to provide consistent support for composite actions in a secure and scalable way, while also unblocking hashFiles path handling at its root.

fix: disable caching (waiting on actions/setup-python#361)

Navigation Menu

Repository navigation

Support cache-dependency-paths outside the current directory #361

11 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support cache-dependency-paths outside the current directory #361

Description

Activity

PeterJCLaw commented on Mar 27, 2022

dmitry-shibanov commented on Mar 28, 2022

dmitry-shibanov commented on Mar 28, 2022

PeterJCLaw commented on Mar 28, 2022

dmitry-shibanov commented on Apr 1, 2022

PeterJCLaw commented on Aug 15, 2023

dmitry-shibanov commented on Aug 17, 2023

zyv commented on Oct 25, 2023

11 remaining items

v-aparnajyothi-y commented on Dec 16, 2024

zhimsel commented on Apr 23, 2025

JasonYang545 commented on Jun 5, 2025

v-aparnajyothi-y commented on Jun 23, 2025

v-aparnajyothi-y commented on Jul 3, 2025

PeterJCLaw commented on Jul 3, 2025

v-aparnajyothi-y commented on Jul 14, 2025

PeterJCLaw commented on Jul 14, 2025

v-aparnajyothi-y commented on Jul 17, 2025

PeterJCLaw commented on Jul 17, 2025

v-aparnajyothi-y commented on Aug 22, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions