How is the self-host story for sourcehut (paid or gratis)?
Is there a turn-key variant with turn-key upgrades a la gitlab omnibus installer?
How is the self-host story for sourcehut (paid or gratis)?
Is there a turn-key variant with turn-key upgrades a la gitlab omnibus installer?
https://man.sr.ht/installation.md
Most people get this done in an hour or two, sometimes with the help of #sr.ht on irc.freenode.net. It's also often made easier by the fact that you can skip any services you don't need, like paste hosting or wikis. By making you go through the steps and set it up, it makes sure to leave you with an understanding of the pieces and how they fit together, so you're better equipped to deal with it if/when it breaks and to adapt it to your particular circumstances. After you set it up, upgrades are usually pretty painless, you just run `apk upgrade` and it takes care of the rest. In general, I think this approach makes a lot more sense than the turn-key Dockerized approach.
I'm not sure I'm a fan of many approaches I've seen (gitlab omnibus is not a docker install, BTW).
You appear to be supporting alpine Linux - and also Debian derived systems - via packackes?
Packages, obviously, is a nice way to install software... If I wanted an appliance - I should set up an alpine vm, install source-hut components I like, point it at a managed postgres instance and a smart mail host - and assume I'll only ever need to do rolling updates via apk - and distro upgrades via alpine?
Is running on Debian likely to be as smooth?
>Packages, obviously, is a nice way to install software... If I wanted an appliance - I should set up an alpine vm, install source-hut components I like, point it at a managed postgres instance and a smart mail host - and assume I'll only ever need to do rolling updates via apk - and distro upgrades via alpine?
Yeah, that's about right. Upgrades are done just by running your normal package manager updates.
>Is running on Debian likely to be as smooth?
The Debian repository is community-maintained, but the maintainer does a good job and a few people have reported sucess using his packages. We also set it up so that upstream releases automatically update the Debian repo. You'll have to depend on him for support, though, not me - his nick is dlax and he hangs out in #sr.ht on irc.freenode.net; and his email is given on the package page. He's a helpful fellow.
Alpine Linux is indeed the officially supported platform, though, and I highly recommend it. I wouldn't dream of running a different system in production, Alpine is simple and reliable and it's easy to fit the whole thing into your head.
> If you remember where you found that link, let me know, so I can update it.
I belive it was the "100% free and open source" link in this very post:
https://sourcehut.org/blog/2020-04-30-the-sourcehut-hub-is-l...
Which goes to: https://git.sr.ht/~sircmpwn/?search=sr.ht
Which does indeed link the repos - which is good - but from a mindset of "how do I self-host?" maybe a bit bare bones.
Looks like if one follows any of the repo links - the install info is at the bottom. May be an artifact of me being on my phone.
As I said, I didn't look very hard.
I really appreciate the no-nonsense/no hype vibe - but at the same time, I really do want a "here's a sane way to get up and running" front and center.
Now, obviously there's a hosted offering - but at my current company we have a few projects that we feel more comfortable self-hosting due to the nature of some of our customers. For some, we avoid third parties, where we can.
And if you're just looking for Git hosting, here is the install doc: https://man.sr.ht/git.sr.ht/installation.md
https://sr.ht/~sircmpwn/sourcehut
In a nice new project hub UI ;)
But both for managers managing many top level projects, and for developers that are part of those (gitlab/yellow, gitlab/pink...)-gitlab falls down a bit on keeping things organized - it's hard to see if issues in yellow is keeping someone busy and so leaving issues hanging in pink.
We have the Analytics feature designed for that [1]. Please be aware of the distinction between Group-level and Project-level analytics described there.
If you have any feedback on how we can improve this feature, or if you have other ideas, please open an issue [2] and share as many details and examples as possible. We'd love to look into it!
Ideally with a filter on which projects to show.
This works for hierarchical structures today, but not across them. (I'm not sure the current data model is easy to bend into this, so it's understandable - it's just one of the few things we've seen that would let us to more of the project mgmnt in gitlab directly).