Support exec command for deploy
User Story
- As an odo user
- I want to be able to use
execcommand as adeploycommand (or as part of thecompositecommand that is defined asdeploycommand as it is allowed by devfile spec - So that I can use for example helm or kustomize commands in my deploy flow (see example)
Acceptance Criteria
- [ ]
/kind user-story
✗ Exec command is not implemented for Deploy
Example
devfile example with exec command in deploy
https://github.com/kadel/demo-odo-springboot/blob/d5956f5a8af41ae28dc4d97e0d9c03c9250c1e27/devfile.yaml#L114
/area devfile-spec
Try to have similar reusable code for exec command for various group kinds like deploy, build, etc. instead of having separate implementation of exec all over odo code.
devfile example with
execcommand in deployhttps://github.com/kadel/demo-odo-springboot/blob/d5956f5a8af41ae28dc4d97e0d9c03c9250c1e27/devfile.yaml#L114
The example devfile uses a container component to execute the exec command. In odo, we spin up such a container in the inner loop only. So for an odo deploy with an exec command for deploy would succeed only if the component is already running in inner loop.
How do we want to handle this situation? @kadel
The example devfile uses a container component to execute the exec command. In odo, we spin up such a container in the inner loop only. So for an
odo deploywith anexeccommand for deploy would succeed only if the component is already running in inner loop.How do we want to handle this situation? @kadel
Good questions. I would say that the container should be automatically created, and then when the command is finished, it should be deleted. But this is interesting discussion that we should probably bring on the Devfile level.
I would say that the container should be automatically created, and then when the command is finished, it should be deleted.
That would mean creating a k8s job with the spec of the specified container. Sounds doable at first glance. But certain attributes of a Devfile container component like endpoints, sourceMapping, dedicatedPod would be unnecessary/useless in this context. Of course, we could just ignore them and focus on the required attributes.
But this is interesting discussion that we should probably bring on the Devfile level.
OK.