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.

[poupryc]

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.

[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.

[melroy89]

@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

[melroy89]

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.

[melroy89]

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?

[melroy89]

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

[melroy89]

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

[melroy89]

@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.

[melroy89]

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).

[carlonluca]

I uploaded 1.13.0: https://hub.docker.com/repository/docker/carlonluca/gitea.

[melroy89]

Nice thx for the update!

[melroy89]

Well, the last message from @tboerger was:

No, because that would require another worker for the ci system

😖 ahaha...

What about GitHub Actions!?

[techknowlogick]

Locking. This is a general statement, but on issues in this project please don't comment with "any news on this?", we are all volunteers and will post to threads if there are updates. Over 400+ people get an email on any comment on issues to our repo, please don't overload their inbox with comments that don't add to the ticket.

Once we get another ARM CI agent we can get this up and running, but until that time this will remain open.

[techknowlogick]

Now that our pipelines use buildkit for building docker images this could be added (one such place would be: https://github.com/go-gitea/gitea/blob/main/.github/workflows/release-nightly.yml#L94)
I will close this, but if someone remains on 32-bit version of arm with docker wants to send a PR it'll get looked at. I recommend only updating the tag workflow for releases, as otherwise the added time to nightly builds would be a significant increase.