Hi Adam,

Sorry for the late response.

Adam Burns writes:

> Hello Olaf,
>
> Thank you for the lovely Christmas present :)
>
> As a learning experiment based off your work, I've cloned your repo &
> configured an RPi arm64 gitlab-runner (on a dedicated arm64 RPi3
> running Devuan Pi chimaera from the nightly images maintained at
> arm-files.devuan.org).

I noticed your fork and was wondering what you were up to ;-)

> Thanks to comprehensive issue notes in Olaf's devuan gitea repo, I
> was able to setup my own fork of the repo and learn enough about
> GitLab CI to generate registration and pipeline tokens for a specific
> arm64 gitlab-runner instance.

Sorry, proper documentation is still on my TODO list. Glad the issue
notes got you up to speed.

> With 3 minor change commits for docker login, building the images &
> pulling from the gitlab container registry to a fresh Devuan Pi now
> appear to work.

Cool! As for the docker login, I'm not sure what needed to be changed
code wise but note that I provision the GitLab Runner with registry
credentials in its ~/.docker/config.json from an environment variable
set in a local .env file read by `docker compose` at runner startup.
That way neither `docker login` nor GitLab CI/CD variables are needed.

> To pull these test arm64 docker containers and try them out:
>
> docker pull registry.gitlab.com/adampeterburns/container-images/devuan:ascii
> docker pull registry.gitlab.com/adampeterburns/container-images/devuan:beowulf
> docker pull registry.gitlab.com/adampeterburns/container-images/devuan:chimaera
> docker pull registry.gitlab.com/adampeterburns/container-images/devuan:daedalus
>
> etc.
>
> Before I post/respond to a gitea issue and/or try to rinse and repeat
> for armel & armhf architectures, I thought I'd reach out for
> thoughts/advice on how to proceed with extending the container
> offerings to all 3 arm architectures.

Pull requests are welcome! Feel free to create issues.

> some thoughts:
>
> - not sure if docker buildx or docker manifest methods might be a
> better next step approach longer term?

I've never had the need so far to support other architectures and don't
know yet what would be involved. I'm open to pointers and suggestions.

> - like paddyhack is currently for amd64, I'm happy to continue to
> offer arm* RPi gitlab-runner specific builders as a transitory step
> until devuan resources can be used (perhaps devuan resourcing can be
> discussed at next dev meeting).
>
> - longer term: for trust, stability, independence, etc. maybe all
> CI/CD components can eventually use internal devuan gitea repo and
> CI/CD facilities.

Fully agree on that but there was mention on this or the DNG list that
running a GitLab instance just to make CI/CD work might be overkill.
IIRC, someone mentioned Drone CI and there are other candidates. Before
going ahead, I really like to revisit the choice of CI/CD solution for
the project (see #2).

> Olaf, once more thank you for your work/christmas gift in getting
> devuan docker containers up and available.
>
> Happy New Year to all.
>
> Adam.
>
> On 25/12/2022 07:34, Olaf Meeuwissen wrote:
>
>> Hi all,
>>
>> Today being Christmas and all, I wanted to give you all a little present
>> by publishing the first Devuan container images on the Docker Hub. They
>> can be found via
>>

>>    https://hub.docker.com/u/devuan

>>
>> There are `devuan/devuan` images as well as `devuan/migrated` images.
>> The former are meant for general use, the latter are used to build the
>> former. Both images are available for all maintained Devuan releases.
>>
>> Code to build, test and publish the images is available at
>>

>>    https://git.devuan.org/paddy-hack/container-images

>>
>> That is also the place to submit issues in case you encounter a bug or
>> have a feature request.
>>
>> Enjoy!

Hope this helps,
--
Olaf Meeuwissen