Live data from Hacker News

Incident with Issues and Pull Requests

githubstatus.com

101–110 of 143 posts

Re: Incident with Issues and Pull Requests

#101
post #80

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.

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.

Re: Incident with Issues and Pull Requests

#103

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

I have this setup running on a Synology NAS at home. I'm currently syncing all of my starred github repos to local storage using a short bash script that runs once a week. Once a repo is in gitea, it pulls any new updates from github every 6 hours or so. It's mostly for archival purposes, just in case something majorly bad happens to github.

Re: Incident with Issues and Pull Requests

#105
post #80

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.

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.

Gitea requires a database which is unwanted feature for "git server" in my little world.

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

#107
post #84

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

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 :)

Re: Incident with Issues and Pull Requests

#108
post #98

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

Yep, just noting for anyone who may not realize that "in mass" isn't really a thing in English.

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

#110
post #107

Earlier 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 :)

That wasn't clear.

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.

Post reply on HN