Hi Boian,

Boian Bonev <bbonev@???> writes:

> [[PGP Signed Part:Undecided]]
> Hi Olaf,
>
> On Sat, 2022-10-15 at 14:26 +0900, Olaf Meeuwissen wrote:
>
> [...]
>
>> 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.

Probably not.

Maybe Devuan can eventually host its own runners for GitLab CI/CD (and
GitHub too?). I'm thinking of using Gitea's push mirror functionality
to set up read-only mirrors there and then piggy-back on their CI/CD
infrastructure when the mirror gets updates. Assuming things work that
way.

# I guess I could also set up runner(s) on my own mini-PC to process
# these jobs.

>> > > > 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 maintain a self-hosted GitLab CE instance at the office. Update it
every month, i.e. with every minor release. I start with a restore from
full-backup to a test instance and test/troubleshoot the upgrade there.

When you upgraded, you did, of course!, nitpick the Changelogs for
breaking changes, right? I see quite a few in 1.16.0 already ... more
in 1.16.1, 1.16.4 and 1.16.5. Does Gitea have any info on upgrade paths
like GitLab does (one minor at a time works, skipping my requiring you
to upgrade to a certain minor first)?

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

Let's not burden the mirrors with more disk space and more bandwidth
requirements if there are well-known, convenient alternatives.

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

ACK and seeing that Devuan has been approved, we really should push
container images there. It's the *natural* place to look for them,
anyway.

> [...]
>> > > > # 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?

Whoever did the heavy(?) lifting, THANKS!

>> [...]
>>   [2]: https://git.devuan.org/paddy-hack/container-images
>>
>> Oops!  I guess I just got myself sucked into volunteering for Devuan
>> ;-)
>
> Good news :)

Now let's get some code up there. Maybe some issues too, so everyone
can see where I would like to go and I think of getting there.
--
Olaf Meeuwissen