I get the feeling that all of this comes from the, from my point of view, conceptual error that the repository should reflect the deployment.
I think all of this is used just to avoid creating a pipeline that generates a Docker image with everything on it and you just override the paths you want to change on instead of replicating the state of deployment inside your repository.
There is also another point that worries me, having all the related packages on the same repo won't facilitate coupling? because it seems really easy with this setup to generate logical paths outside the intended parts (like controllers and such).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I get the feeling that all of this comes from the, from my point of view, conceptual error that the repository should reflect the deployment.
I think all of this is used just to avoid creating a pipeline that generates a Docker image with everything on it and you just override the paths you want to change on instead of replicating the state of deployment inside your repository.
There is also another point that worries me, having all the related packages on the same repo won't facilitate coupling? because it seems really easy with this setup to generate logical paths outside the intended parts (like controllers and such).