Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Act step using docker silently fails when the image access is forbidden #2609

Open
pcarranza opened this issue Jan 11, 2025 · 3 comments · May be fixed by #2610
Open

Act step using docker silently fails when the image access is forbidden #2609

pcarranza opened this issue Jan 11, 2025 · 3 comments · May be fixed by #2610
Labels
kind/bug Something isn't working

Comments

@pcarranza
Copy link

Bug report info

Error: unknown flag: --bug-report

but:


./act_runner-0.2.11-linux-amd64 --version
act_runner version v0.2.11


### Command used with act

```sh
./act_runner daemon --config /etc/act_runner/config.yaml

Describe issue

When docker is correctly logged in to a registry, but the user does not have permission to access the container it is trying to pull, gitea act_runner silently fails the step without providing any feedback on the problem.

Upon a lot of debugging, I reached the error message:

Failed to pull docker image registry.gitlab.com/path_to_the_image_I_want/image_name:hamster: Error response from daemon: Head "https://registry.gitlab.com/v2/path_to_the_image_I_want/image_name/manifests/hamster": denied: access forbidden

The problem is not that access is forbidden, as expected, but that failure is completely silent.

Apologies if this arrives from gitea, but after reviewing the code I see that this issue happens inside act itself, as that's the one that is handling the step.

Link to GitHub repository

No response

Workflow content

jobs:
  monolith:
    runs-on: ubuntu-latest
    steps:
    - name: Login to GitLab Registry
      uses: docker/login-action@v3
      with:
        registry: registry.gitlab.com
        username: ${{ secrets.GITLAB_LOGIN }}
        password: ${{ secrets.GITLAB_TOKEN }}
    - uses: actions/checkout@v4
    - name: Do something
      uses: docker://registry.gitlab.com/path_to_the_image_I_want/image_name:hamster
      with:
        args: echo "We never get to see this"

Relevant log output

Jan 10 20:24:26 dev-01 act_runner[747]: [testing/monolith] [DEBUG]   🐳  docker pull registry.gitlab.com/path_to_the_image_I_want/image_name:hamster
Jan 10 20:24:27 dev-01 act_runner[747]: [testing/workflow]   ❌  Failure - Do something
Jan 10 20:24:27 dev-01 act_runner[747]: [testing/workflow] [DEBUG] expression '${{ github.workspace }}/.cache' rewritten to 'format('{0}/.cache', github.workspace)'

Additional information

No response

@pcarranza pcarranza added the kind/bug Something isn't working label Jan 11, 2025
@ChristopherHX
Copy link
Contributor

act_runner is using this fork https://gitea.com/gitea/act.

Both act cli (as last line Error:) and github-act-runner (in last step via ##[error]) are reporting these error.

The executor should return the error as return value, are you saying act_runner eats such error?

If yes, there might be more errors like this one in this codebase.

@pcarranza
Copy link
Author

Hey @ChristopherHX, thank you for the reply.

Yes, I am aware of the soft mirror, I will still send a PR there too if that works.

The error is being completely eaten, simply because the logDockerResponse receives a nil reader and bails out immediately, and because in this case (where I logged in with a different action), it results in imagePullOptions.RegistryAuth being an empty string, therefore, nothing logs the error.

Mind that this is an edge case, the docker client already has valid credentials, but the credentials are not good enough to reach the image I'm trying to pull (hence the "forbidden" rather than "unauthorized")

The last line in the method returns a nil thus the error ends up being completely eaten.

I have another version with a lot more logging (and some rewrites) I used to troubleshoot this one, but didn't wanted to push that one as I thought that was going to be a lot more intrusive.

@pcarranza
Copy link
Author

Which makes me think that the logging should be happening in line 64 instead of 76.

Let me know if you would like me to update the PR, I would gladly do so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants