Open TMRGZ opened 2 months ago
well, you have pretty much answered your question: for CDS, it's not an option to reset all files used during the training run to the same epoch that the layer is generated on; in this case, 1980-1-1.
So that means the buildpack needs write access to the workspace at buildtime...
If there's a way to relax the permissions in the build container of your CI, I guess it would solve your issue; we have testimonies of people using this new feature successfully in other CI systems (at least we tested with Github Actions during development)
Investigating I found this issue related to the permissions of the workspace directory, seems that Bitbucket restricts the access by default
https://github.com/buildpacks/community/discussions/229
I'll try if just changing the folder permissions works in my case.
Also just to confirm, the files that are being reset are located in the /workspace folder? There is any documentation about what's happening in the CDS process?
Expected Behavior
Everything works and the Docker image is built using CDS
Current Behavior
Possible Solution
Document if a Bitbucket runner image is not supported and if there is a workaround
Steps to Reproduce
Motivations
I want to give developers the availability to create different kinds of Docker images preconfigured in the company parent pom (Standard, Native, CDS and Crac if it's supported in the future). Standard and native work, but CDS gives me this problem
Additional
I have already implemented another workarounds to make the build-image work in Bitbucket Pipelines