[FrameworkBundle] Split "var/build" from "var/cache" when compiling for the "prod" env #57556
Conversation
…or the "prod" env
| if ('prod' === $this->getEnvironment() && Kernel::class === (new \ReflectionMethod(parent::class, 'getCacheDir'))->class) { | ||
| return $this->getProjectDir().'/var/build/'.$this->environment; | ||
| } |
There was a problem hiding this comment.
it feels a bit dirty ... what about a new (temporary?) configuration env? to be used upstream:
symfony/src/Symfony/Component/HttpKernel/Kernel.php
Lines 302 to 303 in 3729c5c
which brings me to; can we get rid of the parent calls in a trait, by making the envs defacto config envs
There was a problem hiding this comment.
I don't understand your proposal sorry (nor its "why"). Please expand if you want.
There was a problem hiding this comment.
e.g. APP_USE_BUILD_DIR=1 so we dont hardcode the prod env and rely on reflection
also im wondering handling the APP_ envs like APP_CACHE_DIR can be dealt with in Kernel as a firt clas feature
There was a problem hiding this comment.
An alternative implementation might be to define APP_BUILD_DIR in .env.prod in a recipe.
There was a problem hiding this comment.
👍 i tend to prefer a pure configuration solution
but isnt the bigger goal to eventually swap the current implementation?
symfony/src/Symfony/Component/HttpKernel/Kernel.php
Lines 300 to 304 in 3729c5c
I think it's time to consider defaulting to having separate build vs cache folders.
#50391 opened the way, then @Okhoshi continued it in #52962, #52981, #54384, with a tweak in #57553.
I know that doing this change will improve the DX of deploying on Platform.sh: the container compilation happening during the offline generation of the container image will be reusable right away, without any step to copy the related artifacts in a writeable folder. I'm confident this can benefit other hosting systems too.
Let's have this discussion and figure out any blockers.