How are dockerized "steps.run" sections supposed to be written?

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?

When specifying a container for the job the contianer is started by the runner and the entrypoint is overridden so the container will stay running.  We then will exec each step specified in the steps of the job inside that container using docker exec. 

Becase we have reusable actions and multiple steps in our jobs rather than a single script the model has to be different from simply starting the container and running the single script through the entrypoint.

1 Like

I see, makes sense. Is alpine containers not work yet then simply a bug, and the workflow I described is in general ok?

We are currently working on some changes to enable alpine containers to work seamlessly so your workflow in general should be just fine.

Update: 9/18/2019 Alpine containers are now support https://github.blog/changelog/2019-09-18-improvements-to-github-actions/.