I need to run the Firestore Emulator as a service container/composition for integration tests.
This is available as part of the official google/cloud-sdk SDK image, if you start it with the right command that is.
I can’t find how to override the default entrypoint in a service container. entry_point doesn’t work. setup and readiness can’t be repurposed for this use case.
Ideally I’d like to avoid building a custom image for this !
Is it possible ?
Thanks
PS: I find the distinction between service container / composition in the CF docs rather unclear. Several pages still refer to “compositions”, but because the syntax for “service containers” actually includes a “composition” key, it’s not clear if the docs are out of date (I think so, they mention “candidates”) or if they really mean “service containers” where it says compositions ! This is confusing and could be improved IMHO.
Just to understand your use case better I looked at the dockerfile of google/cloud-sdk and it doesn’t have an entry point defined Docker Hub
I also tried docker run -it google/cloud-sdk /bin/sh and I get a normal shell as expected.
So if you want to use this image with a special command, why not add the command property in your Codefresh yaml to specify what command you need? Why do you need to change the entry point? Do I understand your use case correctly? Let me know if I am missing something.
Regarding service containers and compositions, there is a note at the top in both pages.
Basically compositions is the old mechanism and service containers is the new mechanism that is much more flexible. Because we dont want to force any customers to migrate, we still support both mechanisms. The underlying implementation is also shared.
Let me know what note would you suggest to add to our docs that explains things more clearly.
Thank you for your reply.
I want to use this image as a service container, not a regular freestyle step. I didn’t find any examples in the docs of starting a service container with a custom command (this is what I really meant by entry point, sorry for the confusion). I tried with commands: but got "Field 'commands' is not supported by compose" , so I assumed it wasn’t possible.
I’ve now just tried again with command: as you suggested and it worked, thanks !
With just one caveat compared to the equivalent docker run : there doesn’t seem to be a default PATH and I had to use /usr/bin/gcloud, otherwise I got this error :
ERROR: Encountered errors while bringing up the project.
Stopping composition
Completed halt of composition
So, this problem is solved, thanks. command: seems undocumented though, so I would just suggest adding it to at least one example in the service container page, or even better : list out all of the supported YAML properties in some reference documentation, and link to it from there.
I actually went to check the Compositions documentation and command: is mentioned there.
This is where I think the docs are confusing : at the top of the service container page it says
Note that while composition steps are still supported, the recommended way to run integrations tests going forward is with service containers.
When reading this I’m expecting a completely different syntax for “service containers”, but as it turns out they still use the composition key. This is what my service container now looks like :
In order to come across command:, I would have needed to go check the “Compositions” documentation, which I had avoided because of this warning at the top of the page. I think the relationship between the two could be made clearer in the docs : apparently it’s not just that compositions are still supported, they are actually still used as part of the service container syntax.