I'm going to self-host my git repos. Any recommendations? The git+nginx would suffice but it does not offer GUI. I need one to see the changes proposed (aka PRs). Gitea is nice, but a bit overkill for my needs. I don't need CI, files hosting, issues, team members, releases, wiki, forking/watching/staring, etc.
Incident with Issues and Pull Requests
101–110 of 143 posts
Re: Incident with Issues and Pull Requests
#102Re: Incident with Issues and Pull Requests
#103I'm considering host a gitea instance backup all of my repos. I have an important fix that need to be deployed right now but there is no way to deploy it in a normal way with our CI which one was setup with Github Action. Fortunately I have a instruction to bypass CI and build the source by myself. But again, Github defeat me because our release workflows are depend on GitOps which are effected by Github issue. Ahhhh…
Gitea's ability to create a local repository as mirror of a remote repository is great for this. You can stay on Github and have your code regularly mirrored locally.
Re: Incident with Issues and Pull Requests
#104Re: Incident with Issues and Pull Requests
#105I'm going to self-host my git repos. Any recommendations? The git+nginx would suffice but it does not offer GUI. I need one to see the changes proposed (aka PRs). Gitea is nice, but a bit overkill for my needs. I don't need CI, files hosting, issues, team members, releases, wiki, forking/watching/staring, etc.
Gitea is pretty light on resources so even though it has a extra functionality you don't need it's not really a resource pig. Unlike say, GitLab.
I'm just looking for "website" (read: interface) that list files over HTTPS, with the ability to show nice looking diffs. Some sort of ssh keys(?) to prevent unauthorized access etc.
Re: Incident with Issues and Pull Requests
#106GitHub outages are very reliable, as I live in Europe and they always come in the afternoon they're a great reminder to go get lunch It's a feature, not a bug!
Re: Incident with Issues and Pull Requests
#107Earlier quoted context omitted.
From an SRE, one of their DB clusters failed. They use Vitess which is great, but it can be prone to hotspots and doesn't auto-shard. Heavy usage (esp. from large customers, rogue jobs) can take down the cluster. When it goes down, it's a PITA to resolve.
This literally isn't true and looks awfully like the talking points of one of our competitors.
To be clear, I _was_ mapping previous incidents with this year's incident — no competitor or hard feelings involved. I really like Vitess, fwiw. And the only thing I really love is FoundationDB :)
Re: Incident with Issues and Pull Requests
#108Earlier quoted context omitted.
The English translation would be something like, “all together, at the same time”. “In mass” isn’t an English idiom.
"en masse" is the term used in English as well.
As you note, en masse is common — enough so that you even don't need to italicize it (although you can).
Re: Incident with Issues and Pull Requests
#109Re: Incident with Issues and Pull Requests
#110Earlier quoted context omitted.
This literally isn't true and looks awfully like the talking points of one of our competitors.
Ah, unbalanced shards via wrong sharding keys was an issue at one point, IIRC. I remember talking with an SRE there when something bad happened at GitHub last year, and I know that this time the current DB cluster failed. To be clear, I _was_ mapping previous incidents with this year's incident — no competitor or hard feelings involved. I really like Vitess, fwiw. And the only thing I really love is FoundationDB :)
Side note: "Autosharding" is largely a myth that unproven databases are touting. Sharding is complex and requires planning and control. Databases that start shuffling data round without oversight produce nasty surprises. Trying to be too magic is normally always a mistake with databases.