Using Docker images from private repository to run actions in

Hi everyone, I am in the process of migrating my CI setup from Drone to using Gitea Actions, and I have run into a problem, which might stem from me not completely understanding how to configure my runner correctly.

What I am trying to do is being able to run my actions in a docker image from my private repository, as its set up with various tools and keys that are “burned” into the image, but it doesn’t seem like the runner can use images that are not on the public Docker repository?

According to the docs, I think I would need to setup a label something like this:


But, I can’t seem to find any mention on how to supply credentials, a PAT or anything anywhere.

Is this possible currently in Gitea?

My previous setup in Drone did this, and at work we use GitLab where I can also supply credentials and URLs for a private Docker image repository.

I did it for case then Gitea and my custom Docker image are both one Docker engine.

If you control the Gitlab Runner yourself, you could simply log in with docker login <registry> beforehand. Then the runner has access to the private images. This is how I do it here.

But, how would I specify that it should use my repository and not the default dockerhub?

It might be that I just don’t fully understand how the runner bootstraps the images, though.

I do think I have found a solution by reading the Github workflow docs, and I think that I have to specify the image to use in the yml file itself, using the container and image keywords, it looks like I can specify a full path and credentials that way, I just haven’t had time to try it yet.

Exactly. It will look like this

    runs-on: ubuntu-latest
      image: ""

Then you can use any image you want. You just have to make sure that the right tools are installed (e.g. NodejS). This is what makes Gitea Actions different from the Gitlab Runner, for example. There it really doesn’t matter what is in the image, because it doesn’t have such strict dependencies.

1 Like

Ah, there are requirements for the image?

Do you know what they are, I haven’t been able to find a definitive list.

Is this just to be able to, for instance, run actions? Or are there basic requirements for the image to function at all?

No, I am not aware of a specific list either. It also depends very much on which action modules you want to use at all (e.g. docker, then you need the docker tools). In any case, you will probably need NodeJS. Just try it out. If something is missing, you’ll notice it. :wink:

Here is an example of an image I build and then store on my gitea instance.

I wanted a docker image that could compile a go binary and also push the complied binary to my gitea instance. My Dockerfile looks like this:

FROM alpine

RUN apk add --update-cache \
    rsync \
    openssh-client \
    tzdata \
    git \
    curl \
    jq \
    && rm -rf /var/cache/apk/*

COPY --from=golang:1.21-alpine /usr/local/go/ /usr/local/go/

ENV PATH="/usr/local/go/bin:${PATH}"

CMD ["/bin/sh"]

I also had to run docker login and specify the URL of my gitea instance. SSL is a ‘requirement’. There are ways of disabling SSL checks and using port 80 instead but I found it to be a headache.

The command I use to build and push the image is:

docker buildx build --no-cache --platform linux/amd64,linux/arm64 --output type=registry -t <gitea_domain>/kcrawford/$(basename $(pwd) | tr 'A-Z' 'a-z'):0.0.4 .

The basename of pwd just ends up being gobuilder (lowercase) in my case, this was a portable way of using the name of the directory as the name of the image. The image also needs a version tag, and I am on revision 4 of my particular image.

This step also builds both an arm and AMD version of the image because I am running my gitea instance on an Orange Pi but also have a desktop for testing.

Then, when I want to use the image in a gitea action, I have:

    runs-on: gobuilder
      image: gobuilder:0.0.3

Let me know if this helps clear things up.

An approach I’m using for a lot of local pipelines on my self-hosted gitea instance is to have the pipeline use ubuntu-latest, specifying catthehacker/ubuntu:act-latest as a docker-capable image to use.

In the steps I then use to run a specific image from my local registry.

This is an example of a local pipeline I do, where I also use the matrix strategy to use a family of images exercising different compiler versions.

I’m still figuring out some things as well, so this is very much still a work in progress. I was previously using Concourse for my local CI/CD.