ci, dev: remove frontend nginx version, dev stack with bundled front …

[ElysaSrc]

The goal of this PR is to simplify the stack by:

• Removing the nginx front image
• Using the gateway front image by default
• Removing various duplications between dockerfiles
• Adding a script to manage all the docker compose stuff

Due to a limitation in Docker Compose not supporting targeting custom targets inside other Dockerfile in additional contexts, I've moved a part of the building system for the front on the Gateway Dockerfile. Not ideal, but does the trick.

NOTE : Before merging we should modify the protrected branch requirement

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.89%. Comparing base (13d0dd3) to head (4c75436).
Report is 8 commits behind head on dev.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@           Coverage Diff           @@
##              dev   #10502   +/-   ##
=======================================
  Coverage   81.89%   81.89%           
=======================================
  Files        1078     1079    +1     
  Lines      107178   107205   +27     
  Branches      724      729    +5     
=======================================
+ Hits        87771    87795   +24     
- Misses      19367    19370    +3     
  Partials       40       40           

Flag	Coverage Δ
editoast	74.17% <ø> (-0.01%)	⬇️
front	89.46% <ø> (+<0.01%)	⬆️
gateway	2.18% <ø> (ø)
osrdyne	3.28% <ø> (ø)
railjson_generator	87.50% <ø> (ø)
tests	88.14% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[flomonster]

LGTM

Maybe we should delete the scripts/host-compose.sh file?

[ElysaSrc]

Various updates : the order of the overrides matters more than I thought, so I switched the way I pars env flags.

[ElysaSrc]

Due to a limitation in Docker Compose not supporting targeting custom targets inside other Dockerfile in additional contexts, I've moved a part of the building system for the front on the Gateway Dockerfile. Not ideal, but does the trick.

Hm, what is the issue here? Why can't we use the latest stage (with everything built) as the front context for gateway?

(If we really can't do that, we could probably still use a separate Dockerfile in front/.)

Either way we must use additional contexts:

• The gateway needs the built front, or
• The front needs the built gateway

No matter how we integrate it, it does require additional contexts that can reference a specific stage of a docker file, a feature allowed by bakefiles but not compose file.

Since in production the front doesn't exist as a service but is bundled in the gateway, I've put the front building in the gateway dockerfile.

[emersion]

Sorry, I still don't understand why we need to reference a specific stage in additional_contexts. Let's say front/docker/Dockerfile builds the frontend (runs these npm commands). Can't gateway use that Dockerfile (specifically, its last stage) and copy the built files over?

I'd prefer to keep the NPM commands inside front/.

[ElysaSrc]

Sorry, I still don't understand why we need to reference a specific stage in additional_contexts. Let's say front/docker/Dockerfile builds the frontend (runs these npm commands). Can't gateway use that Dockerfile (specifically, its last stage) and copy the built files over?

From my understanding you can give it a path but not the built result of another dockerfile. If you find a way to achieve this without a bakefile we can do so, but I've tried without any success.

I'd prefer to keep the NPM commands inside front/.

I'd prefer too.

[emersion]

From my understanding you can give it a path but not the built result of another dockerfile. If you find a way to achieve this without a bakefile we can do so, but I've tried without any success.

Eh, you're correct. It seems like this is compose-spec/compose-spec#336.

[emersion]

Is host+front mode really useful? If one runs in host mode and wants to hack on the front, they'll probably just run it outside docker, no?

[ElysaSrc]

Is host+front mode really useful? If one runs in host mode and wants to hack on the front, they'll probably just run it outside docker, no?

I feel that making this assumption is risky : we do not know each configuration the user is going to have relative to Docker and I believe we should keep it as unopinionated as possible on those subjects.

Also, the same issue exists with Single Worker and Front, there is no guarantee that someone working on Core could not require modifications on the front. I feel we should not remove an easy option for the developers, starting the stack outside docker can be cumbersome.

[clarani]

I think we need to update the README ?

EDIT (by @bougue-pe ):
-> done in #10530

[clarani]

LGTM ✅

[RomainValls]

Tested on Mac, Docker desktop, works great 💪