Can't make final image directory different from the CNB_APP_DIR

[xfrancois]

Summary

I try to build images on Gitlab-CI with CNB. I can't chose the path from which I build the image because of this, but I would like to have a proper hierarchy in the final image.

Example :

My Gitlab-CI job use paketobuildpacks/builder:base as a base image and checkout the code in /builds/myapp (I can't chose that). I need to set CNB_APP_DIR to /builds/myapp, otherwise CNB doesn't know where is the code. But in the final image, the constructed hierarchy is also /builds/myapp and I would need it be /workspace/ for example.

From what I saw, it was possible with the PACK_APP_DIR variable introduced here #35 but it was removed after. #223 seems to talk about the exact issue i'm facing, but without pointing to some solution.

Is there any solution to decorrelate the location of the code used by the buildpacks and the location of the hierarchy in the final image ?

lifecycle version

0.16.0

platform version(s)

0.9

[natalieparellano]

@xfrancois I believe the CNB spec as it stands currently prevents this decoupling. From the platform spec:

• The app image:
  • MUST contain the following Env entries
    • CNB_APP_DIR=<app>
  • MUST have the working directory set to the value of <app>.

If you are invoking the lifecycle directly you could try passing a different value of -app to the exporter, but that may have unexpected results as the source directory might not get exported. pack build supports --workspace to make the source directory configurable, but it uses the same value for every lifecycle phase.

This might be something we could add to the spec if needed, but we'd need to deliberate about it and find the best way to do it.

[xfrancois]

Thank you for your answer. Yes, as it stands, it's hard to use on a constrained environment where we can't chose the source folder (typically on a CI system). I don't know the best way to implement this improvement, but I think it should be considered

[natalieparellano]

Sounds good - as this is a spec change, it would require an RFC (the process can be found here). If you'd be interested in contributing an RFC, I or another maintainer would be glad to assist you in this process.

[natalieparellano]

Blocking on buildpacks/rfcs#282