Cachi2 prefetching is making changes on a source #712
Labels
bug
Something isn't working
Comments
|
We'll need to pass around 2 paths in the request blob - one for the working copy for all operations and one for the original repository path for logging and formatting purposes. |
brunoapimentel
added a commit
to brunoapimentel/cachi2
that referenced
this issue
Jan 20, 2025
To avoid unintended source code modifications, Cachi2 makes a copy of the source directory when some package managers are used (currently, it's being done just for yarn). This creates a problem with project files, since the absolute path of files now is pointing to the temporary working copy. The solution introced by this patch reverts these paths back to the original source dir path. This is intended to be a quick fix, and should only be kept until we solve #712¹. ¹containerbuildsystem#712 Signed-off-by: Bruno Pimentel <[email protected]>
4 tasks
brunoapimentel
added a commit
to brunoapimentel/cachi2
that referenced
this issue
Jan 20, 2025
To avoid unintended source code modifications, Cachi2 makes a copy of the source directory when some package managers are used (currently, it's being done just for yarn). This creates a problem with project files, since the absolute path of files now is pointing to the temporary working copy. The solution introced by this patch reverts these paths back to the original source dir path. This is intended to be a quick fix, and should only be kept until we solve #712¹. ¹containerbuildsystem#712 Signed-off-by: Bruno Pimentel <[email protected]>
brunoapimentel
added a commit
to brunoapimentel/cachi2
that referenced
this issue
Jan 20, 2025
To avoid unintended source code modifications, Cachi2 makes a copy of the source directory when some package managers are used (currently, it's being done just for yarn). This creates a problem with project files, since the absolute path of files now is pointing to the temporary working copy. The solution introced by this patch reverts these paths back to the original source dir path. This is intended to be a quick fix, and should only be kept until we solve #712¹. ¹containerbuildsystem#712 Signed-off-by: Bruno Pimentel <[email protected]>
brunoapimentel
added a commit
to brunoapimentel/cachi2
that referenced
this issue
Jan 21, 2025
To avoid unintended source code modifications, Cachi2 makes a copy of the source directory when some package managers are used (currently, it's being done just for yarn). This creates a problem with project files, since the absolute path of files now is pointing to the temporary working copy. The solution introced by this patch reverts these paths back to the original source dir path. This is intended to be a quick fix, and should only be kept until we solve containerbuildsystem#712. Signed-off-by: Bruno Pimentel <[email protected]>
github-merge-queue bot
pushed a commit
that referenced
this issue
Jan 21, 2025
To avoid unintended source code modifications, Cachi2 makes a copy of the source directory when some package managers are used (currently, it's being done just for yarn). This creates a problem with project files, since the absolute path of files now is pointing to the temporary working copy. The solution introced by this patch reverts these paths back to the original source dir path. This is intended to be a quick fix, and should only be kept until we solve #712. Signed-off-by: Bruno Pimentel <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We only use a working copy of the input source repository for the Yarn backends. All other package manager backends work on top of the input source directly which may result in some operations we perform dirtying the repo which is completely undesirable.
Unlike #707 the global fix isn't as straight forward since the main issue only pops up with integration tests which also compare the contents of our
.build-config.jsonfile where we fill out incorrect path data for allproject_files, using the temporary working copy path instead of the actual input repo.We need to make sure that while all operations are performed on top of the working copy, any generated build-config data are tied to the original input repo path as the temporary working copy is discarded by the time both
.build-config.jsonand SBOM are dumped to the disk.Extends: #707
The text was updated successfully, but these errors were encountered: