Hi Olaf,

On Sat, 2022-10-15 at 14:26 +0900, Olaf Meeuwissen wrote:
..cut..
> > > I would guess you are aware of git.devuan.org and have your
> > > reason(s) for having opted for other choices, but if not,
> > > "git.devuan.org" is (also) an alternative as a publicly available
> > > software repository.
> >
> > That would be perfect for the scripts and files used to build the
> > images.
>
> Indeed, it is.
>
> The reason for my project living life at GitLab.com is that when I
> started it Devuan was still getting things set up (or was debating
> whether to replace its GitLab instance with Gitea).  By the time that
> dust settled, my project was building images on auto-pilot and I
> never bothered to move things elsewhere.  Until now.

OK, clear :) Thanks for sharing some history

> I had an account on Devuan's GitLab instance.  I've created an
> account on the Gitea instance a few days ago and have been looking
> around. What I miss though is CI/CD integration.  I know Devuan has a
> Jenkins server and am curious how to get CI/CD going for projects.
>
> # Not really enthousiastic about using Jenkins though.  Bad
> experience
> # trying to upgrade a Jenkins server courtesy of plugin dependency
> hell
> # a long time ago is to blame for that.

Let me clarify - jenkins is used only for building Devuan's packages,
not as a real CI system. Maybe extending its use is not a good idea.

> > > > There were regular images for all of jessie, ascii, beowulf,
> > > > chimaera and ceres as well as slim, builder and helper
> > > > variants. Together they gobbled up some 30GiB in disk space in
> > > > my personal project space.
> > >
> > > Though I'm not sure it (a git store web gui) is a good place for
> > > publishing releases of anything given it's page rendering
> > > limitations, and perhaps you would want something different for
> > > that.
>
> Looking at the Gitea Package Registry[1], Devuan could add that (for
> some kinds of "packages", after upgrading to 1.17?) but seeing the
> bandwidth limitations that Boian mentioned a bit below that might not
> be advisable.
>
>   [1]: https://docs.gitea.io/en-us/packages/overview/

Upgrading gitea from 1.15.11 to 1.16.x did not work at all - it
segfaults on something, most probably an inconsistency in the DB or
missing/failed schema upgrade. I tried but couldn't find the reason for
the segfault and just reverted gitea back to 1.15.11. I didn't try any
version from the 1.17.x series since the upgrade test itself is quite
intrusive and includes a DB restore after a failure and possibly losing
stuff that was done in the meantime.

> > I do not understand the process of building Docker images at all.
>
> That's OK ;-)  We can't all be understanding everything.  Just leave
> it to others who do understand the process.  I think I've got a fair
> handle on it.

> > But it would be best for the downloadable product to be mirrored -
> > it shouldn't be a problem to run the image build process on the
> > Devuan's infra, but distributing them is best done via the mirror
> > network. To explain the reasons - bandwidth on the infra is
> > limited. It is enough for timely distribution to the mirrors, but
> > not for direct user downloads, especially in case the user base
> > grows.
>
> I guess Boian is refering to the mirrors listed at
>
>   https://www.devuan.org/get-devuan
>
> While that might work, that suggestion got me thinking about ways to
> push container images to one or more of the BIG registries (Docker
> Hub, ghcr.io and quay.io, off the top of my head) and have Devuan
> users consume them from there.

Yes, but as mentioned by onefang there is also the free space
consideration - if we suddenly increase the disk space requirement,
some mirrors may opt out, which is undesirable. On the other hand
adding a separate component to be (optionally) mirrored will take some
time.

Also Tom mentioned this:

https://www.docker.com/community/open-source/application/

Which is Docker Hub from your list above. Seems most appropriate,
especially from the point of view that docker users will easily find
the images there.

> > > > Now GitLab.com is making changes to their Free Tier offering,
> > > > which is what I'm using, and one of those is a 5GiB storage
> > > > limit on personal (and other top-level) namespaces.  This
> > > > change will come into effect on or after 2022-10-19.  Nothing
> > > > will be removed but one will not be able to write any new data
> > > > past that cap. That is, as soon as the limit is enforced I can
> > > > no longer use my personal GitLab.com namespace.
> > > >
> > > > [...]
>
> > From Olaf's post, I get that the biggest problem is the space
> > requirement.
>
> As far as my GitLab.com hosted registry, yes.  Free Tier top-level
> namespaces like mine only get 5GB to play in.  My registries kept
> *all* images that were ever built so it slowly ballooned to 30GB. 
> I'm not sure keeping these historic images is worth the resources,
> though.
>
> > > > I could purchase additional 10GiB storage chunks at USD60/year
> > > > but if I had that kind of money to burn, I think donating it to
> > > > Devuan would be a much better investment.
>
> In case it wasn't clear, that would work out to USD180/year to start
> with and increase over time (unless some policy is enforced to prune
> very old images and free up space).

This path (also the other paths including gitlab) does not seem right
at all.
> > >

..cut..
> > > > # Or maybe Devuan could be added to the Docker Official
> > > > Images...

Looks like the best plan. The only question is who is doing the
registration - preferably one with @devuan.org email. Ralph?

> I have now created an, as of yet empty, project[2].  Seeing that
> there have been no new images since 2021-07-03, I figured I would
> start from scratch (with half an eye on what I've got on GitLab.com
> of course! and another half eye on what is going on with the Official
> Debian image) and look for creative solutions around storage and
> band-width limitations while at the same time getting images out to
> at least one of the BIG container registries.
>
>   [2]: https://git.devuan.org/paddy-hack/container-images
>
> Oops!  I guess I just got myself sucked into volunteering for Devuan
> ;-)

Good news :)

> > >
..cut..

With best regards,
b.