[VEG-1234] Add ability to mount ZAT in a docker container for testing

token-cjg commented 2 years ago

:v:

/cc @zendesk/vegemite

Description

We'd like to be able to run zat in a docker container, so as to be able to work around environment constraints, as well as test various things that can't be tested just by running zat natively.

Tasks

[x] Include comments/inline docs where appropriate

References

JIRA: https://zendesk.atlassian.net/browse/VEG-1234

Risks

Low. Adds a new way of running ZAT, does not touch upon anything that is included in the gemspec.

token-cjg commented 2 years ago

I've given this another once over, this should work now.

The main change is to build the gem and install it in the image, and then set the entrypoint to zat. This allows the image to be run from anywhere.

cl8au commented 2 years ago

I had a quick glance on https://developer.zendesk.com/documentation/apps/app-developer-guide/zat/. Please feel free to ignore me if I misunderstood the context since I am not familiar with ZAT at all. The developer docs contains two commands we may need to cover in your PR.

zat server
zat theme preview These two commands require server to be running locally with custom ports such as 4254 or 4567. I feel these ports need to be exposed from container which the javascript will need to access them when you have zat=true query parameter.

Again, feel free ignore if this does not make sense

cl8au commented 2 years ago

I had a quick glance on https://developer.zendesk.com/documentation/apps/app-developer-guide/zat/. Please feel free to ignore me if I misunderstood the context since I am not familiar with ZAT at all. The developer docs contains two commands we may need to cover in your PR.

zat server
zat theme preview These two commands require server to be running locally with custom ports such as 4254 or 4567. I feel these ports need to be exposed from container which the javascript will need to access them when you have zat=true query parameter.

Again, feel free ignore if this does not make sense

token-cjg commented 2 years ago

Yes, I think that makes sense. So I should EXPOSE 4567 in the Dockerfile. (I believe that port 4254 is an example of a custom port which doesn't need to be supported.) Thanks for the eagle eye!

cl8au commented 2 years ago

Yes, I think that makes sense. So I should EXPOSE 4567 in the Dockerfile. (I believe that port 4254 is an example of a custom port which doesn't need to be supported.) Thanks for the eagle eye!

Yes, I think that makes sense. So I should EXPOSE 4567 in the Dockerfile. (I believe that port 4254 is an example of a custom port which doesn't need to be supported.) Thanks for the eagle eye!

Maybe this is a very nit question and again also feel free to ignore. If zat server supports custom port. should we also support it from your shell script to pass the argument as port if needed in order to let the docker container to expose the port?

cl8au commented 2 years ago

Yes, I think that makes sense. So I should EXPOSE 4567 in the Dockerfile. (I believe that port 4254 is an example of a custom port which doesn't need to be supported.) Thanks for the eagle eye!

Yes, I think that makes sense. So I should EXPOSE 4567 in the Dockerfile. (I believe that port 4254 is an example of a custom port which doesn't need to be supported.) Thanks for the eagle eye!

Maybe this is a very nit question and again also feel free to ignore. If zat server supports custom port. should we also support it from your shell script to pass the argument as port if needed in order to let the docker container to expose the port?

token-cjg commented 2 years ago

Yes, indeed we should, otherwise this will not work. Thanks for the astute observation 🙇

token-cjg commented 2 years ago

ha! yes that's an artifact of lazily copying code. I will fix that.

zendesk / zendesk_apps_tools