for context, in webservice-cli, users can start a buildservice image based webservice without specifying any command.
This works by setting command to empty array [], forcing k8s to use the images entrypoint.
Because we don't allow command to be optional in jobs-api, we don't have a direct equivalence for this.
It's important to think about this if we want a frictionless migration from webservice-cli to jobs-api.
Possible solutions:
- all cmd in jobs-api is optional. if omitted, k8s command fallsback to whatever the image wants it to be. Because this changes a fundamental behaviour of *ALL* jobs for all image types, I've not gamed out the different ways this can bite us.
- since this is a concern for webservice in jobs-api, we can leave the jobs-api as is, and default command legacywebservice model (in the patch that implements webservice in jobs-api), for buildservice images, to web. this works, but will probably break if the default command in the procfile of a buildservice image changes from web to something else. As far as I can tell we use web as the default, but this is more of a convention and not enforced anywhere? meaning something else can be used by someone knowledgable enough.
- we can have a keyword command (maybe something like __ENTRYPOINT__) and when used, jobs-api accurately detects this and sets k8s command to []. this would mean we don't need to make much change to the validation since __ENTRYPOINT__ is a valid string. possible risk is that a user can literally specify __ENTRYPOINT__ and have k8s command default to image entrypoint, but maybe it's not such a bad thing. in anycase if we do this we would need to document it properly.