As a context, I’m used to gitlab CI, where the general workflow of exectution block in a CI pipeline is
- define the docker image in which the code is supposed to be executed
- define meta-info for the block (e.g. run conditions, artifact paths, …)
- define the actual shell script that is going to be run
I expected something similar for execution block in actions, where the equivalent sectios would be
- define docker image in jobs.<job_id>.container.image
- define meta-info in jobs.<job_id>.* (excluding container.image and steps)
- define the actual script that is going to be run
The way I read it, the script would be executed given the –entrypoint of the used image. So usually some kind of shell, but maybe also python or any other script language that one can dockerize (by the way, this would be an amzing feature, and was the reason why I wanted to try out actions). But it doesn’t work that way, because actions hacks the entrypoint before running the steps.
Is there a good reason why? Since jobs.<job_id>.container.options are included before the the entrypoint override, I can’t even define a working entrypoint myself, so there is no good workaround. Or am I just approaching this tool with the wrong set of expectations?