Skip to content

Bug when parsing runs.image value in action.yml #1416

Closed
@m1chu-alle

Description

I have been redirected here by GH support.

It looks like there is a bug connected to a value of runs.image in action.yml and execution of docker run (inside workflow step containing created action). I did below tests on v2.283.3 of actions/runner.

Typical usage

When creating Docker contained action we use such directory schema as a standard example:

|-- .github
    |-- action.yml
    |-- Dockerfile
    |-- entrypoint.sh

Action file might look like this:

# action.yaml
# ...
runs:
  using: 'docker'
  image: 'Dockerfile'
# ...

Content of Dockerfile and entrypoint.sh doesn't matter in these cases.

More complex usage

Let's imagine a situation when we want to keep two or more actions with a similar profile in one repository.

We can divide directories using the following directory schema:

|-- .github
     |-- action-a
          |-- action.yml
     |-- action-b
          |-- action.yml
     |-- docker
          |-- action-a
               |-- entrypoint.sh
          |-- action-b
               |-- entrypoint.sh
          |-- Dockerfile.a
          |-- Dockerfile.b
          |-- shared.sh

You might ask why we extract some files into separate docker directory?
This separation allows to load shared files (such as shared.sh) in both entrypoint.sh files. Shared file is a level higher in directory hierarchy and as we know Docker only allows adding (COPY, ADD) files from within Dockerfile directory and its children.

However, this is not the key problem in the whole case. With the above layout both action.yml files need to have such entry to work properly:

  using: 'docker'
  image: './../docker/Dockerfile.a'
  # OR
  # image: './../docker/Dockerfile.b'

Executing above actions ends with the following error (example):

/usr/bin/docker run --name dockerDockerfilea_336f1e --label cf4eaa ...
docker: invalid reference format: repository name must be lowercase.

Lowercasing above complex usage

It seems that the given image path (./../docker/Dockerfile.a) has been reformatted to a name (dockerDockerfilea_336f1e). Docker doesn't like uppercases in repository name.

So I changed Dockerfile.a name to dockerfile.a and put ./../docker/dockerfile.a into image property. In parallel, I made the same change for the second Dockerfile.b.

  using: 'docker'
  image: './../docker/dockerfile.a'
  # OR
  # image: './../docker/dockerfile.b'

Sadly, executing changed actions ends with the following error (example):

/usr/bin/docker run --name dockerdockerfilea_0ed722 ...
docker: invalid reference format.

Fixing above complex usage

Interestingly, there is a simple workaround for the above problem. You need to reverse the file name with file extension. Instead of:

  using: 'docker'
  image: './../docker/dockerfile.a'
  # OR
  # image: './../docker/dockerfile.b'

I used this:

  using: 'docker'
  image: './../docker/a.Dockerfile'
  # OR
  # image: './../docker/b.Dockerfile'

My directory structure looks like this:

|-- .github
     |-- action-a
          |-- action.yml
     |-- action-b
          |-- action.yml
     |-- docker
          |-- action-a
               |-- entrypoint.sh
          |-- action-b
               |-- entrypoint.sh
          |-- a.Dockerfile
          |-- b.Dockerfile
          |-- shared.sh

This change caused that action has been executed correctly. As you can see Dockerfile extension started with a capital letter. In this approach it doesn't matter, whether the first letter is capitalized or not (case insensitivity).

Conclusion

In the examples we have two naming conventions for multiple Dockerfiles cases:

  • Dockerfile.sufix-extension, which is allowed by Docker, but doesn't work in GitHub Actions
  • prefix-naming.Dockerfile, which is not prohibited by Docker and works in GitHub Actions

It looks like a bug. However, it is possible that such an implementation is due to some specific reasons. Where do such discrepancies result from?

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions