You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Cache doesn't work when the project is not in the root of the repository. #476
Description:
Add an input to the action (working-directory or project-directory) to specify the path to the project, where the pyproject.toml file is located. Use this directory to look for the pyproject.toml and cached deps.
Justification:
Caching doesn't work for projects where the project is not in the root of the repository.
Hello everyone!
We've released v4.5.0 action version. Could you please try using it and check that everything is working as expected and the issue is fixed?
@MaksimZhukov seems like still not fixed because we can't specify working-directory or project-directory.
If you have monorepo with 20 different projects, have no sense to run find by **/poetry.lock pattern.
Basically, you are solving a different issue - you have one project but not at the root. This issue is about - in your root folder you have multiple projects and you should pick up one.
Hello Everyone, We’ve raised PR #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 to proceed further.
Feel free to reach out if you have any questions or need further clarification.
Hello Everyone, Just a quick reminder — we’ve raised PR #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.
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.
Activity
IvanZosimov commentedon Aug 8, 2022
Hi, @atayardimci 👋 Thank you for the feature request, we will take a look at it and get back to you with updates.
dongho-jung commentedon Aug 22, 2022
I've been workarounding it as follows for now
I hope this feature request be integrated into setup-python : )
dmitry-shibanov commentedon Oct 3, 2022
Hello @atayardimci. Sorry for the late response. Could you please try to specify
cache-dependency-pathwith the path topyproject.toml?atayardimci commentedon Oct 3, 2022
Hi @dmitry-shibanov. I had already tried that, but it didn't work as expected.
dmitry-shibanov commentedon Oct 3, 2022
Hello @atayardimci. Could you please provide a public repository to reproduce the issue ?
nschonni commentedon Oct 3, 2022
@dmitry-shibanov you can find an example with a poetry.lock in mdn/yari#7236
stalkerg commentedon Oct 24, 2022
I have a totally same issue because using monorepo. My root is not the root of the project.
jbacon-cfs commentedon Nov 29, 2022
Same issue!
MaksimZhukov commentedon Jan 12, 2023
Hello everyone!
We've released v4.5.0 action version. Could you please try using it and check that everything is working as expected and the issue is fixed?
MaksimZhukov commentedon Feb 6, 2023
I am closing the issue, since the new release should fix it.
Please let us know if you are still facing this issue.
Thanks!
stalkerg commentedon Feb 7, 2023
@MaksimZhukov seems like still not fixed because we can't specify
working-directoryorproject-directory.If you have monorepo with 20 different projects, have no sense to run find by
**/poetry.lockpattern.Basically, you are solving a different issue - you have one project but not at the root. This issue is about - in your root folder you have multiple projects and you should pick up one.
Base on this PR #447
stalkerg commentedon Mar 30, 2023
Any progress?
ci: remove next cache
test: add e2e smoke tests for headless-ssr utils (#3093)
v-aparnajyothi-y commentedon Jun 12, 2025
Hello Everyone, We’ve raised PR #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 to proceed further.
Feel free to reach out if you have any questions or need further clarification.
v-aparnajyothi-y commentedon Jun 17, 2025
Hello Everyone, Just a quick reminder — we’ve raised PR #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.
v-aparnajyothi-y commentedon Jul 3, 2025
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.
v-aparnajyothi-y commentedon Aug 22, 2025
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.