codeberg dependency | Dagger | Page 1

tropic solar Feb 25, 2026, 5:30 PM

#

hrm, yeah I've been intentionally branching out from GitHub for gestures wildly reasons, this is the first time I've seen codeberg be down, looking into it now. there's also a dependency on https://codeberg.org/vito/tuist as of yesterday, so it goes beyond submodules

Codeberg.org

tuist

#

status page at least reflects it, but no way to look farther back: https://status.codeberg.org/status/codeberg

Codeberg Service Status

This is an overview of the Codeberg Infrastructure. Uptime stats are calculated over the past 24 hours only.

<a href=https://social.anoxinon.de/@codeber

#

lol the downtime is pretty quickly moving out of the visible window - it was half red before 😅

brittle fractal Feb 25, 2026, 5:41 PM

#

@tropic solar I don't think you using codeberg is an issue at all... However it does highlight our excessive dependency on external services at runtime

#

The extra weird component is that we don't actually need any of the bits that are on codeberg. That fetch-all-submodules behavior is perhaps not the right default? 🤔

tropic solar Feb 25, 2026, 5:43 PM

#

IMO it's correct - but should maybe be configurable opt-out depending on the context

#

the only hope for submodules to ever work in a reasonable way is for them to be fetched by default imo. Dang's tests for example depend on them

brittle fractal Feb 25, 2026, 5:44 PM

#

Mmm true we have no choice but to assume the whole repo content is needed, sub-modules included

tropic solar Feb 25, 2026, 5:44 PM

#

but it's definitely true that those submodules aren't needed for the core function of the dang SDK

#

and fetching them adds unnecessary overhead

brittle fractal Feb 25, 2026, 5:46 PM

#

In the specific case of dang, we should talk about bundling 🙂

#

Especially since the whole point is speed...

#

Maybe we can decouple A) git repo migration from B) build-time bundling?

#codeberg dependency