Do not build container actions ahead of time

[umarcor]

jobs:

  job:
    runs-on: ubuntu-latest
    steps:
    
    # BUG: GitHub's runner tries to build the last action before starting the first step.
    # It fails, because container image image_name does not exist yet.
    
    - name: Build hdlc/doc
      run: |
        docker build -t image_name - <<-EOF
        FROM asciidoctor/docker-asciidoctor
        RUN apk add -U --no-cache graphviz
        EOF
        
    - uses: actions/checkout@v2

    - uses: docker://image_name
      with:
        args: doc/make.sh

As a result, it is currently not possible to use local containers using the uses: docker:// syntax.

The alternative is to call docker explicitly, which requires handling all the environment manually (if necessary):

jobs:

  job:
    runs-on: ubuntu-latest
    steps:

    - name: Build hdlc/doc
      run: |
        docker build -t image_name - <<-EOF
        FROM asciidoctor/docker-asciidoctor
        RUN apk add -U --no-cache graphviz
        EOF

    - uses: actions/checkout@v2

    - name: Build site
      run: docker run -v /$(pwd)://documents/ image_name ./doc/make.sh

Using local docker images in container steps should be supported too.

This is somehow related to #9049, because being able to use variables in uses: steps requires not to build them ahead of time.

[ethomson]

Thanks for the feedback. We don't have any plans to change the lifecycle of container actions at the moment.

We may be able to loosen this restriction for container-based jobs; it's something that we'll explore.

You could workaround this at the moment by having separate jobs: one that builds your image and publishes it to DockerHub or GitHub Container Registry, and then a second job that runs a container-based job using that container. This is obviously a bit more heavyweight but it's more in the spirit of the way Actions and Packages were imagined to work together.

[umarcor]

@ethomson, I think that this restriction does not apply to container-based jobs, because in those cases there is no step building a container for a later step. The image needs to exist since the begining.

I agree that using multiple jobs is possible. However, that creates unnecessary traffic and noise. There are many use cases where pushing to a registry makes sense. In many others, it's a cumbersome burden.

With regard to container jobs, they are pretty limited, because most reusable Actions are not meant to be executed on containers, but on the default virtual environments. Therefore, I try to use container steps only.

Anyway, as explained above, it is possible to solve the problem by not using GitHub's syntax, and relying on the docker CLI instead.

[ethomson]

I'm curious what precisely you mean when you say "container steps"?

[umarcor]

@ethomson, with Container Step I mean the "Using Docker Hub action", "Using GitHub Packages Container registry" and "Using a Docker public registry action" examples of section jobs.<job_id>.steps[*].uses of the "Workflow syntax" page in the GitHub docs: https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepsuses. See also https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepswithargs. So:

• Container Job: a job with field container.
• Container Action: a step with field uses: namespace/repo/path/to/action@version, pointing to location with an action.yml.
• Container Step: a step with field uses: docker://image/name.

In practice, the only difference between a Container Action and a Container Step is that the Action requires a configuration file (action.yml), while the Step does not require it. Since the environment and the args can be used to pass parameters, the configuration file and the inputs are redundant in most cases.