chore: add docker-compose-mac-dev.yml #628
Conversation
|
@jshimkus-rh Are there pre-reqs to this PR |
|
@mkanoor That's what @Alex-Izquierdo was concerned about. Try as I might I couldn't make that happen; don't know why and it's not worth it right now to figure it out. I've gone back to the previous handling (see my latest commit) of |
tools/docker/docker-compose-mac.yml
Outdated
| @@ -33,7 +54,10 @@ services: | |||
| condition: service_healthy | |||
|
|
|||
| eda-api: | |||
| image: "${EDA_IMAGE:-quay.io/ansible/eda-server:main}" | |||
| image: "${EDA_IMAGE:-localhost/aap-eda}" | |||
There was a problem hiding this comment.
@jshimkus-rh Does this mean now we have to provide an EDA_IMAGE env var to get to use the default image from quay.io. Shouldn't this default the other way around. By default we use quay unless the developer wants to override it. If we have a UI developer who wants to use podman they have to change the EDA_IMAGE to point to quay.io/ansible/eda-server:main because they will never build the eda-server locally.
There was a problem hiding this comment.
The question I infer from this is what is the purpose of the different compose files?
As a developer of the "engine" (i.e., something functional even w/o a UI; the desirability of which, product-wise, appears to be somewhat unclear based on things I've heard) who uses a Mac I'm interested in default establishment of an "engine" development environment. The differences between the *-mac.yaml and *-dev.yml files which have accumulated making the two development environments differ is a "bad" thing and my motivation in more closely aligning them.
That is not to say there isn't a need for what you describe, though rather than having a single file that has to pull double-duty I think it is preferable to have a specific, shall we say, "canned" compose for that purpose. With changes that have been made in relation to podman support it appears that docker-compose-stage.yaml provides that. If not, we could easily create such.
There was a problem hiding this comment.
I agree with @jshimkus-rh In linux we want to run the current code by default, not the quay image. Maybe the point here is what mimics the mac version, the dev environment or the stage one.
There was a problem hiding this comment.
@Alex-Izquierdo We have 2 kinds of developers 1 developing the UI and another developing the API Server. If I am a UI developer I don't want to build the API Server image and if I am an API Server I don't want to build the UI image. If this tool needs to be embraced by both kinds of developers the default needs to be fetch standard quay images and a developer can override their local ones to use the image of their choice. In Mac there is only 1 docker file unlike the dev and stage in Llnux. If we are using local builds we just override the EDA_IMAGE and everything else falls into place. When we started the EDA-SERVER development we used to build the UI and server images locally and use them locally. Now the patterns are changing we use standard quay images as much as possible and even for local PR testing we have been pushing images to our private quay repos and making the images public so we can test without waiting for a final approval on the PR. Using quay images improves the speed of development across team members, allows for sharing of images akin to storing binaries in an ftp server without having to build anything locally.
jshimkus-rh
force-pushed
the
updated-mac-compose
branch
from
6e9fe91 to
695c632
Compare
jshimkus-rh
changed the title
|
This has been changed to the addition of a |
This file closely matches the docker-compose-dev.yaml file.
jshimkus-rh
force-pushed
the
updated-mac-compose
branch
from
165f121 to
44561c6
Compare
Makes docker-compose-mac.yml largely identical to docker-compose-dev.yaml. Hopefully this will make it easier to incorporate future updates between (in both directions) the files easier.