Docker image being pulled despite negative condition

Hi,

if I have something like

jobs:
  steps:
    - name: Rebase Action
      if: github.event.issue.pull_request != null && github.event.comment.body == '/rebase'
      uses: docker://cirrusactions/rebase:latest

then I see the Docker image being pulled bespite the if condition evaluating to false (and thus the step being marked as “neutral”), see e.g. https://github.com/sschuberth/action-playground/commit/139964a18aa1f356de127b2838a32c524b5378de/checks. This obviously is sub-optimal, so is there a way pulling of the Docker image can be avoided in this case?

This eager pulling of images also prevents authenticating with private image registries.

For example, something like this will never work, as the image is attempted to be pulled before auth is completed.

jobs:
  steps:
- name: Authenticate with ECR
run: eval "$(aws ecr get-login --region "us-west-2" --no-include-email)"
    - name: Some action using a private ECR image
      uses: docker://xxxx.dkr.ecr.us-west-2.amazonaws.com/image

We pull actions at the start of workflow runs for a handful of reasons - we need to ensure that they exist in the “set up” process so that we can rely on them.  And, unfortunately, that means that we do need to pull it down even though you might not end up using it.  (We can’t evaluate the condition at set up time, since it may depend on values that are populated after the set up but before the action runs).

We do want to make repository automation workflows like the one you’re using more efficient, but I’m curious what the goal of avoiding that docker pull is?

> We can’t evaluate the condition at set up time, since it may depend on values that are populated after the set up but before the action runs.

Well, I’d say that’s a rather common problem in systems with interdependencies, and build systems like Gradle solve it by introducing another pass (the “configuration phase”) that first populates all relevant values, eliminating any unneeded tasks / steps, and then executing the actions.

> I’m curious what the goal of avoiding that docker pull is?

Mainly, shorten the action’s runtime (even more), but also avoiding unnecessary network traffic, just because it’s right to do so.

> Well, I’d say that’s a rather common problem in systems with interdependencies, and build systems like Gradle solve it by introducing another pass (the “configuration phase”) that first populates all relevant values, eliminating any unneeded tasks / steps, and the executing the actions.

Agreed.  There are some optimizations that we can make here, just explaining the rationale for the behavior at present.

> Mainly, shorten the action’s runtime (even more), but also avoiding unnecessary network traffic, just because it’s right to do so.

Got it.  :+1: Noble goals, and things we want to optimize for as well.  We’ll improve scenarios like this, but I think that it won’t be until we’re out of the beta that we’re able to tackle some of these optimizations in earnest.