Gitea: Provide ARM Docker Image

[pennal]

It would be great if you could provide an already built docker image on Docker Hub for ARM platforms such as the Raspberry Pi (>= 2). From what I have seen the pipeline seems to be already set up, and the Dockerfile seems to exist.

Thanks!

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[denji]

It should be: armhf ( GOARCH=arm | GOARM=7).

[brinsche]

There is https://github.com/go-gitea/gitea/blob/master/Dockerfile.rpi already but it looks like it differs a little from the normal Dockerfile. The last time it was updated (#386) the rpi-Dockerfile wasn't also updated

[tboerger]

You are right, it got smaller differences. Currently we don't have a arm pipeline running, but hopefully we can provide that soon

[tboerger]

Somebody wants to create a pr to bring the files back in sync?

[appleboy]

This issue should be closed by #548

[tboerger]

No, it's not solved because we don't publish this image yet.

[appleboy]

@tboerger Understood.

[Solido]

In the same continuity not all NAS support docker. Some big brand like Synology offers a .spk deployment mechanism and there's no doubt that a tools like Gitea can be find on such platform a very fast pace of adoption.

[flipswitchingmonkey]

There's an SPK builder for Gogs gogs-spk which I've forked for Gitea gitea-spk
Tried it with 1.0.1 on a Synology DS116 and it works fine so far.

[ulm0]

is there any docker image for rpi yet?

[tboerger]

@klud1 only the Dockerfile, no prebuilt image so far

[ulm0]

@tboerger cloned the repo yesterday, tried to build it. then i realized i needed a gitea binary that is copied into the image (got an error saying /app/gitea/gitea: no such file or directory), wanted to build the gitea binary (installing build-essential and golang, the latter by downloading it from the golang website) and got some make [error] when attempting to build it, altought i go get the libraries needed for this. then i just downloaded the gitea binary from the website (https://dl.gitea.io/gitea/1.0.1/gitea-1.0.1-linux-arm-7) and granted execution permission in order for it to be copied in the image, but still docker logs [container name] output /app/gitea/gitea: no such file or directory.

any idea how can this be successfully achieved?

[chadweimer]

@klud1 Same problem here using a Raspberry Pi 3. I cloned the repo, then make clean generate build followed by docker build -f Dockerfile.rpi .. I'm seeing the same 'no such file or directory' error when starting the container.

[ulm0]

@chadweimer i recently got it working, just changed some things in the dockerfile, built it and tested it and it all seems to work fine, here is the Dockerfile in case you want to see it.

[chadweimer]

@klud1 That's great! I suspected it was something in the image since I was able to build and run outside docker. I tried a few things but wasn't able to figure it out. Any chance you can post your changes here? I'm not able to access that file on your GitLab repo, even after signing in.

[ulm0]

@chadweimer oh, gosh! you're right, i can't access it when singing out either, it shows a 404 error, even though it's set as a public project. So sorry. Here is the Dockerfile:

FROM armhf/alpine:3.5

ENV USER git
ENV GITEA_CUSTOM /data/gitea
ENV GODEBUG=netdns=go

RUN apk update && \
  apk add \
    su-exec \
    ca-certificates \
    sqlite \
    bash \
    git \
    linux-pam \
    s6 \
    curl \
    openssh \
    wget \
    tzdata && \
  rm -rf \
    /var/cache/apk/* && \
  addgroup \
    -S -g 1000 \
    git && \
  adduser \
    -S -H -D \
    -h /data/git \
    -s /bin/bash \
    -u 1000 \
    -G git \
    git && \
  echo "git:$(date +%s | sha256sum | base64 | head -c 32)" | chpasswd

COPY docker /
RUN mkdir -p /app/gitea && \
    wget -O /app/gitea/gitea https://github.com/go-gitea/gitea/releases/download/v1.1.0/gitea-1.1.0-linux-arm-7 && \
    chmod +x /app/gitea/gitea

EXPOSE 22 3000

VOLUME ["/data"]

ENTRYPOINT ["/usr/bin/entrypoint"]
CMD ["/bin/s6-svscan", "/etc/s6"]

You also need the docker folder in the gitea repo in order to get it working.

[kfordaccela]

Please note that you will want to update the release that you're using from the correct release at the following url. https://github.com/go-gitea/gitea/releases after which you can do a rebuild and restart th container with a command like the following.

docker run -d --restart=always --name=gitea-arm_1.3.2a -p 1022:22 -p 3000:3000 -v /opt/gitea:/data 9f93a41afd45

I usually do a remove of the old image after starting the new one, no issues with the upgrade path.

[HelloEdit]

So are you planning to automatically publish an arm64 image? if so, you might be interested in the arm64v8 repo which offers arm64 compatible docker images of the most popular images (node, rust, busybox...). Maybe adding a gitea here could be an interesting compromise as described here?

[lafriks]

we do but first we need move to using builtin ssh server in official docker image.

[lunny]

@lafriks yes, maybe we could do that on docker:latest but docker:1 keep OpenSSH currently.

[lafriks]

@lunny yes we can do that only after we have release/v1.6 branch

[tboerger]

Currently we can only build amd64 because we need to install system packages and we only got an amd64 ci worker. If we get rid of the system packages like OpenSSH and git we can cross compile the binary and push the other architecture images, as long as we install system packages we need native agents.

[sapk]

@tboerger we can also build the container for other platform via qemu but that is not ideal.

[tboerger]

This sucks pretty much if we look at the size of our CI agents ;)

[fkrull]

Something I think is not widely known (so if you do know, feel free disregard my comment ;) ) is that it's now possible to build and run foreign-architecture Docker images without changing the image itself, so long as you have root access to the Docker host (or the ability to run arbitrary privileged containers).

As it happens, I have a Docker image that sets up qemu and binfmt so you can transparently build foreign-arch images and run foreign-arch binaries and containers. So if you have the option to set up something like this on your CI nodes, you should be able to build ARM images without dealing with base images including qemu or similar hacks.

[sapk]

@fkrull that what I mean by qemu I even made a PR https://github.com/go-gitea/gitea/pull/3958 but that still a little hacky and need full privilege in CI jobs.

[fkrull]

@sapk Yeah, that's the kind of thing I was thinking of. Carry on, then. :D

[Kunde21]

I mentioned this in another issue, but I have an unofficial multi-arch (arm/arm64/amd64) manifest built with sqlite support published on docker hub. Keep in mind that this is not automated, yet. Pushed the v1.6.2 release last week, to bring it up to date.

[killua99]

@Kunde21 I wish to help you to keep that docker image update. How could I help you with that task? I thought that would be better rather to poke you to update the docker image with the latest gitea version.

[techknowlogick]

@killua99 @Kunde21 We just upgraded to Drone 1.0.0 which allows mult-arch agents, so we can build an official image, in case you'd be open to sending a PR to our CI instead of maintaining it yourself. More details here: #6463

[killua99]

That's a great news @techknowlogick I'll start looking at them asap

[Kunde21]

It's a bit of bash ugliness, but this is the build script I use on all arches. The key is to ensure that the arch is included in the docker tag, so everything can be pushed to the registry and a manifest generated for the multi-arch entry.

PATH=$PATH:/gopath/bin
GITEA_VERSION=v1.7.2

GODEBUG="netdns=go"
TAGS="bindata sqlite"

ARCH=$(case $(uname -m) in x86_64) echo "amd64"; ;; armv*) echo "arm"; ;; aarch64) echo "arm64"; ;; esac)
GITEA_VERSION=${DRONE_TAG-$GITEA_VERSION}

echo "$ARCH-$GITEA_VERSION" > .tags

apk update 
apk upgrade
apk add --no-cache git \
    bash \
    linux-pam \
    curl \
    make \
    tzdata \
    gcc \
    musl-dev \
    openssl \
    openssh \
    openssh-client \
    sqlite \
    sqlite-libs \
    wget ;

go get -u github.com/jteeuwen/go-bindata/...

wget https://github.com/go-gitea/gitea/archive/$GITEA_VERSION.tar.gz -O ../gitea.tar.gz
tar xf ../gitea.tar.gz --strip-components=1

go generate ./...

mkdir build_artifacts
go build -v -o ./build_artifacts/gitea -tags "$TAGS" -ldflags="-s -w -X 'main.Version=$GITEA_VERSION' -X 'main.Tags=$TAGS'"
mv docker ./build_artifacts/docker

./build_artifacts/gitea -h

[Kunde21]

Sorry @killua99, just bad timing. I'm in the middle of a move, so my home cluster is torn apart right now.

The setup I use to build:
1 rpi-3 (Arch Linux, ARMv7)
1 rpi-3 (Arch Linux, aarch64)
1 NUC (Arch Linux, amd64)

I have 3 drone deployments connected to a gitea server. So, a push to the repo builds all 3 arches and pushes to my registry and docker hub. I usually create the manifests via CLI, because it's pretty quick.

If you want to replicate this setup, one key is putting a performant USB drive in each rpi3 to use as a big swap drive. That relieves the memory pressure when building sqlite, so the build will succeed.

[atomi]

By the way, Alpine apk has a --print-arch flag.

[Kunde21]

Ahh, thank you. I was originally building in Ubuntu, so I tried to make it as agnostic as possible. The --print-arch trick is nice!

[tboerger]

Uname is not reliable for architecture detection...

[atomi]

Yeah, why not? I'm able to build Gitea on an rpi 3 b by adding a a couple of gigs to swap and I've been running GItea on it just fine.

If you're using Drone CI you can use their manifest plugin http://plugins.drone.io/drone-plugins/drone-manifest/ or create the manifest manually using a Makefile i.e. https://github.com/miniflux/miniflux/blob/master/Makefile

[onedr0p]

@atomi I deleted my comment after realizing gogs wasn't a AIO image

I am hoping to use Gitea on my k3s cluster.

[tboerger]

Maybe somebody could give my unofficial webhippie/gitea image a try, it provides a manifest for arm6 and arm8.

[joel-wright]

The webhippie/gitea image seems to be working well for me, thanks @tboerger 🙂

Edit:... under Raspbian Buster & docker-ce on a Raspberry Pi 4

[sapk]

The :latest tag is providing multi-arch support for linux/amd64 (tagged :linux-amd64) and linux/arm64 (tagged :linux-arm64). We will need to setup other drone builder for each platform has we don't do cross build.

[ZetaPhoenix]

@sapk,

Is it possible to add armhf to the drone builder?

[6543]

just to mention it here, https://github.com/alpinelinux/aports/pull/10887 will upgrade the alpine gitea package wich could also be used for docker images

[everflux]

Just to provide feedback: Running gitea/gitea ARM64 successfully ( 1.11.0+dev-348-g2011a5b81 ) - thanks a lot!

[sk-t3ch]

@tboerger hey, i've managed to get your Gitea ARM image running on my Raspberry Pi 4, but I cannot get my custom app.ini to be loaded. Any chance of seeing the dockerfile? I can't find any reference to it on docker hub.

[tboerger]

@sk-t3ch good hint, since I'm uploading the README of the repo to DockerHub it doesn't link to the repository anymore... You can find the whole source at https://github.com/dockhippie/gitea

[kerberjg]

Can confirm the ARM64 image runs pretty well! However I'd love to see an ARMv6/7 image for RPi 2 and lower

[tboerger]

Can confirm the ARM64 image runs pretty well! However I'd love to see an ARMv6/7 image for RPi 2 and lower

Until there is an official one you could use webhippie/gitea which is built for arm64v8, arm32v6 and amd64 ;)

[manisto]

@everflux, did you actually get the gitea/gitea:latest image to run on your Raspberry Pi? I feel like I've tried everything with no luck.

[sk-t3ch]

Hey @manisto - check it out here https://medium.com/@t3chflicks/home-devops-pipeline-a-junior-engineers-tale-1-4-336ed07a6ec0?utm_source=share

[sk-t3ch]

Sorry @manisto I meant this one https://medium.com/@t3chflicks/home-devops-pipeline-a-junior-engineers-tale-2-4-7be3e3c292c?utm_source=share

[everflux]

@manisto yes I am running the gitea/gitea image from DockerHub on ODROID N2 with Archlinux ARM / arm64 as kubernetes pod. Works great so I don’t expect any trouble when running on Raspberry pi neither. (If you are using raspian I assume this is usually a 32bit flavor but docker should resolve that properly.)
What error do you get?

[ulm0]

@manisto is your rpi os 64bit?

[Kunde21]

@manisto If you're running on 32-bit, then you can use kunde21/gitea-arm or webhippie/gitea images. Both have arm variants in the manifest.

[gpanders]

The webhippie/gitea image uses different environment variables than the gitea/gitea image, which means the installation instructions don't work when using that image.

When using that image I'm not able to get to the install page and any environment variables I specify in the docker compose file seem to be ignored.

[tboerger]

This image disables the installer on purpose, all settings can be set by env variables. The first registered user will be the initial admin. I'm currently thinking about creating an initial admin user from env variables, then I'm able to use this container for automated integration tests for drone.

[danger89]

@tboerger Please provide a armv7 as well! I'm running a Banana Pi.. I would love to host it on there.. But I can't ;( Is it very hard to compile for arm7 as well during your CI/CD pipeline? And provide the docker image.

ERROR: no matching manifest for linux/arm/v7 in the manifest list entries

[tboerger]

No, because that would require another worker for the ci system. But you can run the arm6 image on arm7

[carlonluca]

@danger89 if you want I have images for armv6, armv7 and arm64. I am using it on pi 2, pi3 and pi4.
https://hub.docker.com/repository/docker/carlonluca/gitea

[danger89]

No, because that would require another worker for the ci system. But you can run the arm6 image on arm7

That is not how docker work:

@carlonluca Thanks, but for some reason those dockers aren't working on my banana pi. It says its up. But often it won't load my app.ini correctly or doesn't use the same environment variables. Or whatever is wrong.

I just want to use the official docker images, on my pi.

[carlonluca]

@danger89 use the latest-official tag. That comes straight from the official Dockerfile.

[danger89]

Just :latest right? Which is the default tag. Yes, I tried that.. It isn't working. Or you mean another latest tag?

[carlonluca]

Tag is "latest-official": https://hub.docker.com/layers/carlonluca/gitea/latest-official/images/sha256-ed0f1a2d72f580d0c34f342df1594f4ca0be0e322774e031fed6f51471e4abb6?context=repo

[tboerger]

@danger89 have you tried webhippie/gitea?

[danger89]

Tonight I will try this latest official tag. I will keep you posted. Thanks

[danger89]

Well carlonluca/gitea image using the latest-official tag is at least working. Let's see how easy it is to migrate my data. Back-up script is provided, still missing an easy restore script.

I think I'm facing some (not issue related) migration issues. Where the database is from version gitea version 1.13.0, and now the latest stable on arm is gitea version 1.12.5 (so a down grade in minor release).

This is something Gitea doesn't like :)

on /explore/repos page:

template: explore/repo_list:32:9: executing "explore/repo_list" at <.DescriptionHTML>: error calling DescriptionHTML: unrecognized repo unit type: 8

[danger89]

@carlonluca I think I wait a bit longer when the stable release v1.13 is out.

Once you then update the latest-official tag again, I think I'm able to easily migrate from my x86 setup to my BananaPi.

[lunny]

1.13rc1 is out.

[carlonluca]

I built the new image but it is not working for me on arm64, sorry. Latest-official remains the latest stable. I'll build the following stable versions.

[danger89]

Over 1 week or so, I expect to see v1.13 stable release to be rolled out. I also would not advice to change the latest-official tag, until the stable release is created (iso RC-versions).