Provide ARM Docker Image #180

@tboerger commented on GitHub (Dec 31, 2016):

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

@tboerger commented on GitHub (Dec 31, 2016): Somebody wants to create a pr to bring the files back in sync?

GiteaMirror commented

@appleboy commented on GitHub (Jan 1, 2017):

This issue should be closed by #548

@appleboy commented on GitHub (Jan 1, 2017): This issue should be closed by #548

GiteaMirror commented

@tboerger commented on GitHub (Jan 1, 2017):

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

@tboerger commented on GitHub (Jan 1, 2017): No, it's not solved because we don't publish this image yet.

GiteaMirror commented

@appleboy commented on GitHub (Jan 2, 2017):

@tboerger Understood.

@appleboy commented on GitHub (Jan 2, 2017): @tboerger Understood.

GiteaMirror commented

@Solido commented on GitHub (Jan 9, 2017):

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.

@Solido commented on GitHub (Jan 9, 2017): 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.

GiteaMirror commented

@flipswitchingmonkey commented on GitHub (Jan 15, 2017):

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.

@flipswitchingmonkey commented on GitHub (Jan 15, 2017): There's an SPK builder for Gogs [gogs-spk](https://github.com/alexandregz/gogs-spk) which I've forked for Gitea [gitea-spk](https://github.com/flipswitchingmonkey/gitea-spk) Tried it with 1.0.1 on a Synology DS116 and it works fine so far.

GiteaMirror commented

@ulm0 commented on GitHub (Feb 18, 2017):

is there any docker image for rpi yet?

@ulm0 commented on GitHub (Feb 18, 2017): is there any docker image for rpi yet?

GiteaMirror commented

@tboerger commented on GitHub (Feb 18, 2017):

@klud1 only the Dockerfile, no prebuilt image so far

@tboerger commented on GitHub (Feb 18, 2017): @klud1 only the Dockerfile, no prebuilt image so far

GiteaMirror commented

@ulm0 commented on GitHub (Feb 18, 2017):

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

@ulm0 commented on GitHub (Feb 18, 2017): @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](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?

GiteaMirror commented

@chadweimer commented on GitHub (Mar 25, 2017):

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

@chadweimer commented on GitHub (Mar 25, 2017): @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.

GiteaMirror commented

@ulm0 commented on GitHub (Mar 27, 2017):

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

@ulm0 commented on GitHub (Mar 27, 2017): @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](https://gitlab.com/klud/gitea/blob/master/Dockerfile) in case you want to see it. ![screenshot from 2017-03-26 21-30-56](https://cloud.githubusercontent.com/assets/13160093/24336821/29e83a6e-1263-11e7-943a-752da7304b9d.png)

GiteaMirror commented

@chadweimer commented on GitHub (Mar 27, 2017):

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

@chadweimer commented on GitHub (Mar 27, 2017): @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.

GiteaMirror commented

@ulm0 commented on GitHub (Mar 27, 2017):

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

@ulm0 commented on GitHub (Mar 27, 2017): @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.

GiteaMirror commented

@kfordaccela commented on GitHub (Jan 26, 2018):

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.

@kfordaccela commented on GitHub (Jan 26, 2018): 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.

GiteaMirror commented

@poupryc commented on GitHub (Oct 15, 2018):

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?

@poupryc commented on GitHub (Oct 15, 2018): 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](https://github.com/docker-library/official-images#contributing-to-the-standard-library)?

GiteaMirror commented

@lafriks commented on GitHub (Oct 15, 2018):

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

@lafriks commented on GitHub (Oct 15, 2018): we do but first we need move to using builtin ssh server in official docker image.

GiteaMirror commented

@lunny commented on GitHub (Oct 16, 2018):

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

@lunny commented on GitHub (Oct 16, 2018): @lafriks yes, maybe we could do that on docker:latest but docker:1 keep OpenSSH currently.

GiteaMirror commented

@lafriks commented on GitHub (Oct 16, 2018):

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

@lafriks commented on GitHub (Oct 16, 2018): @lunny yes we can do that only after we have `release/v1.6` branch

GiteaMirror commented

@tboerger commented on GitHub (Oct 16, 2018):

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.

@tboerger commented on GitHub (Oct 16, 2018): 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.

GiteaMirror commented

@sapk commented on GitHub (Oct 16, 2018):

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

@sapk commented on GitHub (Oct 16, 2018): @tboerger we can also build the container for other platform via qemu but that is not ideal.

GiteaMirror commented

@tboerger commented on GitHub (Oct 16, 2018):

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

@tboerger commented on GitHub (Oct 16, 2018): This sucks pretty much if we look at the size of our CI agents ;)

GiteaMirror commented

@fkrull commented on GitHub (Oct 16, 2018):

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.

@fkrull commented on GitHub (Oct 16, 2018): 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](https://github.com/fkrull/docker-qemu-user-static) 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.

GiteaMirror commented

@sapk commented on GitHub (Oct 16, 2018):

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

@sapk commented on GitHub (Oct 16, 2018): @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.

GiteaMirror commented

@fkrull commented on GitHub (Oct 16, 2018):

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

@fkrull commented on GitHub (Oct 16, 2018): @sapk Yeah, that's the kind of thing I was thinking of. Carry on, then. :D

GiteaMirror commented

@Kunde21 commented on GitHub (Dec 25, 2018):

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.

@Kunde21 commented on GitHub (Dec 25, 2018): I mentioned this in [another issue](https://github.com/go-gitea/gitea/issues/2607#issuecomment-340724456), but I have an unofficial multi-arch (arm/arm64/amd64) manifest built with sqlite support published on [docker hub](https://hub.docker.com/r/kunde21/gitea-arm). Keep in mind that this is not automated, yet. Pushed the v1.6.2 release last week, to bring it up to date.

GiteaMirror commented

@killua99 commented on GitHub (Mar 28, 2019):

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

@killua99 commented on GitHub (Mar 28, 2019): @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.

GiteaMirror commented

@techknowlogick commented on GitHub (Mar 28, 2019):

@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

@techknowlogick commented on GitHub (Mar 28, 2019): @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

GiteaMirror commented

@killua99 commented on GitHub (Mar 28, 2019):

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

@killua99 commented on GitHub (Mar 28, 2019): That's a great news @techknowlogick I'll start looking at them asap

GiteaMirror commented

@Kunde21 commented on GitHub (Apr 1, 2019):

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 commented on GitHub (Apr 1, 2019): 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. ```bash 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 ```

GiteaMirror commented

@Kunde21 commented on GitHub (Apr 1, 2019):

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.

@Kunde21 commented on GitHub (Apr 1, 2019): 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.

GiteaMirror commented

@atomi commented on GitHub (Apr 1, 2019):

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

@atomi commented on GitHub (Apr 1, 2019): By the way, Alpine apk has a `--print-arch` flag.

GiteaMirror commented

@Kunde21 commented on GitHub (Apr 1, 2019):

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!

@Kunde21 commented on GitHub (Apr 1, 2019): 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!

GiteaMirror commented

@tboerger commented on GitHub (Apr 1, 2019):

Uname is not reliable for architecture detection...

@tboerger commented on GitHub (Apr 1, 2019): Uname is not reliable for architecture detection...

GiteaMirror commented

@atomi commented on GitHub (Jul 18, 2019):

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

@atomi commented on GitHub (Jul 18, 2019): 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

GiteaMirror commented

@onedr0p commented on GitHub (Jul 18, 2019):

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

I am hoping to use Gitea on my k3s cluster.

@onedr0p commented on GitHub (Jul 18, 2019): @atomi I deleted my comment after realizing gogs wasn't a AIO image I am hoping to use Gitea on my k3s cluster.

GiteaMirror commented

@tboerger commented on GitHub (Jul 18, 2019):

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

@tboerger commented on GitHub (Jul 18, 2019): Maybe somebody could give my unofficial webhippie/gitea image a try, it provides a manifest for arm6 and arm8.

GiteaMirror commented

@joel-wright commented on GitHub (Jul 30, 2019):

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

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

@joel-wright commented on GitHub (Jul 30, 2019): The webhippie/gitea image seems to be working well for me, thanks @tboerger 🙂 Edit:... under Raspbian Buster & docker-ce on a Raspberry Pi 4

GiteaMirror commented

@sapk commented on GitHub (Jul 30, 2019):

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.

@sapk commented on GitHub (Jul 30, 2019): 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.

GiteaMirror commented

@TheRogueZeta commented on GitHub (Sep 7, 2019):

@sapk,

Is it possible to add armhf to the drone builder?

@TheRogueZeta commented on GitHub (Sep 7, 2019): @sapk, Is it possible to add armhf to the drone builder?

GiteaMirror commented

@6543 commented on GitHub (Sep 8, 2019):

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

@6543 commented on GitHub (Sep 8, 2019): 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

GiteaMirror commented

@everflux commented on GitHub (Dec 1, 2019):

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

@everflux commented on GitHub (Dec 1, 2019): Just to provide feedback: Running gitea/gitea ARM64 successfully ( 1.11.0+dev-348-g2011a5b81 ) - thanks a lot!

GiteaMirror commented

@sk-t3ch commented on GitHub (Jan 18, 2020):

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

@sk-t3ch commented on GitHub (Jan 18, 2020): @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.

GiteaMirror commented

@tboerger commented on GitHub (Jan 19, 2020):

@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

@tboerger commented on GitHub (Jan 19, 2020): @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

GiteaMirror commented

@kerberjg commented on GitHub (Jan 28, 2020):

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

@kerberjg commented on GitHub (Jan 28, 2020): Can confirm the ARM64 image runs pretty well! However I'd love to see an ARMv6/7 image for RPi 2 and lower

GiteaMirror commented

@tboerger commented on GitHub (Jan 28, 2020):

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

@tboerger commented on GitHub (Jan 28, 2020): > 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 ;)

GiteaMirror commented

@manisto commented on GitHub (Mar 15, 2020):

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

@manisto commented on GitHub (Mar 15, 2020): @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.

GiteaMirror commented

@sk-t3ch commented on GitHub (Mar 15, 2020):

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 commented on GitHub (Mar 15, 2020): Hey @manisto - check it out here https://medium.com/@t3chflicks/home-devops-pipeline-a-junior-engineers-tale-1-4-336ed07a6ec0?utm_source=share

GiteaMirror commented

@sk-t3ch commented on GitHub (Mar 15, 2020):

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

@sk-t3ch commented on GitHub (Mar 15, 2020): Sorry @manisto I meant this one https://medium.com/@t3chflicks/home-devops-pipeline-a-junior-engineers-tale-2-4-7be3e3c292c?utm_source=share

GiteaMirror commented

@everflux commented on GitHub (Mar 15, 2020):

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

@everflux commented on GitHub (Mar 15, 2020): @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?

GiteaMirror commented

@ulm0 commented on GitHub (Mar 15, 2020):

@manisto is your rpi os 64bit?

@ulm0 commented on GitHub (Mar 15, 2020): @manisto is your rpi os 64bit?

GiteaMirror commented

@Kunde21 commented on GitHub (Mar 16, 2020):

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

@Kunde21 commented on GitHub (Mar 16, 2020): @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.

GiteaMirror commented

@gpanders commented on GitHub (Mar 25, 2020):

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.

@gpanders commented on GitHub (Mar 25, 2020): The `webhippie/gitea` image uses different environment variables than the `gitea/gitea` image, which means the [installation instructions](https://docs.gitea.io/en-us/install-with-docker/) 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.

GiteaMirror commented

@tboerger commented on GitHub (Mar 26, 2020):

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.

@tboerger commented on GitHub (Mar 26, 2020): 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.

GiteaMirror commented

@melroy89 commented on GitHub (Oct 4, 2020):

@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

@melroy89 commented on GitHub (Oct 4, 2020): @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`

GiteaMirror commented

@tboerger commented on GitHub (Oct 4, 2020):

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

@tboerger commented on GitHub (Oct 4, 2020): No, because that would require another worker for the ci system. But you can run the arm6 image on arm7

GiteaMirror commented

@carlonluca commented on GitHub (Oct 4, 2020):

@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

@carlonluca commented on GitHub (Oct 4, 2020): @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

GiteaMirror commented

@melroy89 commented on GitHub (Oct 6, 2020):

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.

@melroy89 commented on GitHub (Oct 6, 2020): > 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: ![image](https://user-images.githubusercontent.com/628926/95145386-5ac27f80-077b-11eb-96f0-8f35962a03e1.png) @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. ![image](https://user-images.githubusercontent.com/628926/95146399-fe149400-077d-11eb-80ba-7f1002ecb6c2.png) I just want to use the official docker images, on my pi.

GiteaMirror commented

@carlonluca commented on GitHub (Oct 6, 2020):

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

@carlonluca commented on GitHub (Oct 6, 2020): @danger89 use the latest-official tag. That comes straight from the official Dockerfile.

GiteaMirror commented

@melroy89 commented on GitHub (Oct 6, 2020):

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

@melroy89 commented on GitHub (Oct 6, 2020): Just :latest right? Which is the default tag. Yes, I tried that.. It isn't working. Or you mean another latest tag?

GiteaMirror commented

@carlonluca commented on GitHub (Oct 6, 2020):

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

@carlonluca commented on GitHub (Oct 6, 2020): Tag is "latest-official": https://hub.docker.com/layers/carlonluca/gitea/latest-official/images/sha256-ed0f1a2d72f580d0c34f342df1594f4ca0be0e322774e031fed6f51471e4abb6?context=repo

GiteaMirror commented

@tboerger commented on GitHub (Oct 6, 2020):

@danger89 have you tried webhippie/gitea?

@tboerger commented on GitHub (Oct 6, 2020): @danger89 have you tried webhippie/gitea?

GiteaMirror commented

@melroy89 commented on GitHub (Oct 6, 2020):

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

@melroy89 commented on GitHub (Oct 6, 2020): Tonight I will try this latest official tag. I will keep you posted. Thanks

GiteaMirror commented

@melroy89 commented on GitHub (Oct 7, 2020):

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 commented on GitHub (Oct 7, 2020): 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 ```

GiteaMirror commented

@melroy89 commented on GitHub (Oct 8, 2020):

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

@melroy89 commented on GitHub (Oct 8, 2020): @carlonluca I think I wait a bit longer when the stable [release v1.13](https://github.com/go-gitea/gitea/milestone/67) 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.

GiteaMirror commented

@lunny commented on GitHub (Oct 15, 2020):

1.13rc1 is out.

@lunny commented on GitHub (Oct 15, 2020): 1.13rc1 is out.

GiteaMirror commented

@carlonluca commented on GitHub (Oct 17, 2020):

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.

@carlonluca commented on GitHub (Oct 17, 2020): 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.

GiteaMirror commented

@melroy89 commented on GitHub (Oct 17, 2020):

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

@melroy89 commented on GitHub (Oct 17, 2020): 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).

GiteaMirror commented

@carlonluca commented on GitHub (Dec 3, 2020):

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

@carlonluca commented on GitHub (Dec 3, 2020): I uploaded 1.13.0: https://hub.docker.com/repository/docker/carlonluca/gitea.

GiteaMirror commented

@melroy89 commented on GitHub (Dec 3, 2020):

Nice thx for the update!

@melroy89 commented on GitHub (Dec 3, 2020): Nice thx for the update!

GiteaMirror commented

@heliomcp commented on GitHub (Dec 7, 2020):

Any news for an official docker for arm?

$ docker pull gitea/gitea
Using default tag: latest
latest: Pulling from gitea/gitea
no matching manifest for linux/arm/v7 in the manifest list entries

@heliomcp commented on GitHub (Dec 7, 2020): Any news for an official docker for arm? ```bash $ docker pull gitea/gitea Using default tag: latest latest: Pulling from gitea/gitea no matching manifest for linux/arm/v7 in the manifest list entries ```

GiteaMirror commented

@melroy89 commented on GitHub (Dec 14, 2020):

Well, the last message from @tboerger was:

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

😖 ahaha...

What about GitHub Actions!?

@melroy89 commented on GitHub (Dec 14, 2020): Well, the last message from @tboerger was: > No, because that would require another worker for the ci system 😖 ahaha... What about GitHub Actions!?

GiteaMirror commented