docker login fails on self-hosted runner

[mauritsvanrees]

TLDR: I don't know what is going on, but I will make a PR with a small fix so you can pass an empty username or password and not authenticate with docker login. The current version seems to want to support that, but the shell logic does not work for me.

In a big Volto project (Cookieplone based) that I work on with @fredvd we are using kitconcept/docker-stack-deploy@v1.2.0. This is done on a self-hosted runner. Until the end of last year, deployment from the main branch to a development server went fine. Now after a slow period we are making changes again, and deployment fails with:

"Container Registry: Login to ghcr.io as mauritsvanrees failed"

That is output from this line in the docker entrypoint, which is the result of the docker login command failing.

As username we pass ${{ github.actor }} and as password a secret on the repo that contains a classic Personal Access Token from GitHub with only read:packages scope. The PAT belongs to a separate service account

I wondered if the PAT had expired, so I made several tries to get a working PAT in the secrets, but the command kept failing. I tried explicitly using the service user instead of the github.actor, but with a PAT the username seems basically ignored, as far as I see.

So I thought I would first call docker/login-action with the GitHub actor and secrets.GITHUB_TOKEN, which works for building and pushing a new image. And then call kitconcept/docker-stack-deploy without passing username and password. But the code that tries to determine if the username or password are empty seems wrong: I don't pass anything, but the code still thinks these are not empty, so it tries to login anyway, which obviously fails. I have a PR ready for that. When I use my own fork with that fix, the deploy works again.

So I hope my fix can get in.

But I would also be interested to know if anyone else has seen this problem lately, and knows what is going on. I suspect the self-hosted runner, which has been updated recently, but I tried an older version and that fails as well.

[davisagli]

I haven't seen this (but I'm not using self-hosted runners).

I would be concerned about doing the deployment while authenticated using secrets.GITHUB_TOKEN rather than a PAT. Docker will pass the auth info along and pulling the image will succeed during the deployment, but then if the container moves to a different node later, it will not be able to pull the image using the expired token.

[mauritsvanrees]

Do you mean that if we pass a secret along, be it a PAT or a short-lived GITHUB_TOKEN, this gets stored on the server/stack/swarm/node for future use? So if a day later the swarm (or an admin) decides to start a container on a different swarm node it will try to re-use this secret?

If that is the case, you are probably right. The same would be true for PAT though, but then only once a year or so.

This should not be a problem in our case, because we have everything on one host, so the image is already there.