This is a nice reminder that you can have multiple remote repos and push/pull to all of them at the same time. For my side projects I usually use both github and google cloud source (I use gcp). If one is down the other is still available and then just resync when service is recovered.
No, I do not. Usually though it is easy since whatever reconciliation you did in one repo you can do in another. The only difficulty is if you rewrite remote history, so don’t do it!
See, I like the idea of K8S quite a lot. Enough that I decided to set up a cluster from scratch to figure out how everything ties together.
I've since grown to strongly dislike how much of the entire ecosystem seems to depend on random unversioned Github gists or direct links into a raw file in a repo somewhere.
NPM is the same. You might think that all of the packages are stored on NPM servers. Mostly true, but still when you install some of them they'll download precompiled binaries or whatever directly from Github.
Eh, I'd love to see numbers on this but I don't think this is true. I remember stuff like homebrew breaking even in the beginning of the project because of the dependency on github to pull down formulas and stuff.
I remember it being a weekly occurrence before Microsoft as well.
edit: though their historical data doesn't back it up. It's just a 2020 thing it seems; coincidentally picked up right near the middle of February which correlates way too closely with the beginning of COVID.
The whole "correlation does not imply causation" thing is completely misunderstood.
The issue is with the meaning of the word "imply"; when used in the formal sense as it appears is Classical Logic, correlation does indeed not imply causation.
In common parlance however, "imply" is often used to mean "provides evidence for", and correlation can indeed provide (potentially strong) evidence for a hypothesised causal link; the problem lies in people reading "correlation does not imply causation", assuming the informal meaning of "imply", and then going on to reject any notion of causation which uses observed correlation as evidence.
Pretty much every empirical science uses notions of correlation (in its various formal statistical guises) to provide support for causation, indeed to reject such reasoning would be to invalidate huge swathes of mainstream accepted science; half the battle in these instances is making the leap from correlation to causation in a manner which is considered scientifically sound.
From what I understood, they are having capacity issues with one of their MySQL masters or something. I've read that they are in process of sharding/resolving that but it takes time.
To GitHub SRE/oncall people: hang in there, you're awesome.
Yeah, our builds are failing for a couple of hours now, and we just use Github because one of the dependencies in NPM downloads a binary from a public repository. We're already forking what we can to our gitlab self-hosted server, but even a simple git clone or even browsing the website can lead to a HTTP 500 right now.
Lots of incidents lately, but it's becoming increasingly hard to get away from Github.
I said this before many times and I'll say it again, consider self-hosting your projects on a solution like GitLab or Gitea to avoid this sort of situation. [0]
GNOME, Xfce, Redox, Wireguard, KDE and Haiku all have self-hosted on either cgit, Gitlab, Phabricator or Gitea.
I used to help maintain Xfce's svn and then git server.
I'm not going to say it was hard, but it was work, and it was work that took time (time that was volunteer free time) away from working on Xfce itself. When I did the final git imports of our svn repos in mid-2009, GitHub had been around for about a year, maybe a year and a half, and wasn't that popular yet. And I suppose back then I had the bull-headed "must self-host because that's the only thing a respectable open source developer should do".
That was a foolish attitude that took time away from the actual goal, which was making Xfce better. If it were today, I would have moved us to GitHub in a heartbeat, or perhaps GitLab (their hosted offering; I wouldn't self-host), instead. I haven't been involved with Xfce (still a happy user though!) in nearly a decade, but I suspect they still self-host out of inertia, with probably a little of that bull-headedness mixed in (that I myself can't claim to be fully free of either).
While GitHub's uptime isn't perfect, it's pretty damn good, and better than most volunteers will get running their git server off a single box someone had racked somewhere in Belgium, which I believe was what we were doing at the time. Tools for that sort of thing are better now, and if I had to self-host today, I'd use EC2 or something like that, and automate the hell out of everything, but it's still a lot more work than just using somebody else's infra.
In fact, with all these free services, I'd probably say it's well worth automatically making remotes (at least) for GitLab, GitHub and having a local Gitea for everything you do. This should be resilient against specific outages, or GitHub simply deciding they don't like your project name, or some other disaster.
No guarantees either way - Google Code was alive and kicking, until it suddenly wasn't.
I do appreciate how easy git and other dvcs make it to mirror repositories, though. I find myself using Github mirrors of projects that are otherwise self-hosted, just because the code search works on Github works pretty well.
Funny, I find myself cloning GitHub repos just because code search on GitHub works pretty badly (e.g. it doesn't pick up partial tokens). Haven't had the chance to compare to other solutions though.
Self-hosting is hard work, you easily forget security updates, or backups, and should your project get a lot of traffic your server might not handle it.
And should your project go unmaintained it'll probably disappear if you don't have managed hosting.
How about a more low-tech solution? I don't want/need a full-blown web application like Gitlab, just need somethings than auto-syncs my public and private repos so that i can still access everything when Github is down.
If you are working alone on these projects, store bare git repository in Dropbox and/or similar services that sync data through all your devices.
If more privacy is required, you can use something like gocryptfs to only send encrypted data to these services.
Syncthing is a similar option that doesn't require an external service, also doesn't require local encryption since all data in transit is always encrypted.
This has a big caveat though: there's no locking mechanism that will work reliably on the bare git repo, so you may have to resolve some conflicts manually if two separate devices push to the same git repo at the same. This is why you should only use this method of you work alone on these repos.
It's still a full full blown web app but I can highly recommend gitea. It's just a single binary so getting setup is really easy. I run an instance and it literally requires no maintenance.
never trust external tools in your build process, you may have an emergency and not be able to fix.
we are trying to migrate to https://www.sonatype.com/nexus-repository-oss (self hosted), it would cache the git tags and you just have to replace the git links to nexus like in the dependency manager.
if you want something simpler, you can try satis for php, sinopia or verdaccio for npm packages. you will find a lot of other tools for the other languages.
I wouldn't consider self hosting better with regards to downtime. Our company has various self hosted components like jenkins and all and full time people to manage that, and I can say for sure their downtime is more than github. And good luck if you think you can manage everything for a side project.
I personally haven't experienced any SD card corruption, even though I am running a Maria-DB instance, Home-Assistant instance and a Pi-Hole instance on a Pi Zero with a 32 gig SD Card ( 23 days uptime as of writing )
It typically kicks in after a few months depending on the stuff you're running and type of SD Card. SD Cards aren't really designed for the type of read/write patterns a 24/7 Raspberry Pi server would entail.
I've had 2 sd-cards go corrupt (read-only, any writes were lost). Had a mariadb instance running on it as well. It will hold for for some time, but eventually, the card will give up.
I run a cosy Gitea hosting service over at https://hostedgitea.com/ for those who want their own private Gitea box without the hassle of deploying or maintaining it. Basically I handle all that for you myself. Just starting out but happy to get feedback!
I changed the i18n of Gogs to s/Organization/Folder/, which I think works pretty well, though I'm becoming more interested in gitea's fork. I reckon the same trick will work.
Dont forget that change in software is inherently risky and will result in bugs, etc. Id rather have a platform that is always looking to make things better and risking a bit of downtime, than a stale platform that we all know we depend on.
What if we had a smart failover. Use GitHub and GitLab simultaneously. All issues, all comments, all PRs duplicated. If one goes down you use the other one in the time being with no interference at all. One can probably then build a frontend which magically does this failover for ci/CD etc. Isn't that's how much redundant this should be?
It is. We all have our own copy of the repository, and can still distribute changes using any of the other methods:
- A different central server
- Email
- A shared on-filesystem copy, e.g. local network drive
- HTTP or SSH between developer computers (put your repository somewhere where your NginX or Apache serves it, the other developer can "git remote add chvid http://chvid.example.com/repository").
My main dislikes are slow, lazy loading, and that you can’t read the last commit messages without extra clicks of the “...” button. Even in pull requests I’ve seen new commits show up without the message (and clicking the expand button, it closed itself after a few seconds).
There have been some other annoyances/changes in behaviour that have bugged me too, but mostly stopped remembering them because am resigned to it now.
the repo top bar is wider than the rest of the content. It feels unbalanced. Personally I'm not a fan of that part. No complaints about any other change.
I just had to access my Github stars to find an old app I bookmarked. No dice. Otherwise I've moved all my current projects to Gitlab so Stars and contributing to other repos are my two most used features atm.
in my build pipeline, I query several different package hosts (npm, pypi, docker-hub etc) and Github/Gitlab. If any of them is unavailable, the build fails.
What's the best way to keep my own copy of the packages my software needs (and their dependencies), so that my build process is less fragile? Ideally, I'd only have to rely on those 3rd party platforms to download new versions or have them as a backup.
When relying on my own copy of required packages - can I expect much faster builds?
I still don't understand people who always mentions to Microsoft's acquisition. Until the official statement, it isn't Microsoft failure. Don't blame them.
It's not MS fault, of course, but since MS acquired GH, GH has been much more relaxed. New features are added all the time, clearly not ready for the spotlight. It gives you a different comfort knowing your daddy is there as a safety net.
I used to self-host everything and while I never had hiccups or problems, I got tired of the additional work of maintaining a git server and moved my personal projects to github just so I don't have to deal with it. I suppose the comments are fueled by frustration and the fact that when you have something in-house, you can directly go and push the devops teams to fix it whereas github you just sit and wait. I never understood why people think that poking someone with a stick will magically speed up the fixing process but there we go...
Git is notionally decentralized. It should be neither as difficult or uncommon as it is to have multiple repositories, but we have collectively let convenience get in the way of reliability.
But those wouldn't take most of the world's public git repos down all at once just because of a single issue. Single points of failure have a bad reputation for a reason.
Absolutely not, but I guess that most of "internal repos" access patterns are widely less trafficked than GH. So, it's not that difficult to have a "stable enough" configuration for most organizations. Sure, for a 5-10 devs shop it's overkill, but if you have a mid-sized team and already having someone caring for internal tooling/systems, it's not that a bad idea. Unless you have the "hosted here" syndrome.
Umm, so if you are hosting your own Git Repos, and not fiddling with the configurations much once you have found the perfect fit.
Isn't the only reason it will go down be because of network issues or power failure? What other possible cause could be for system failure?
I have been running HA, Pi-Hole, Maria-DB and my own API instances on my Raspberry Pi and in the 22 days of uptime till now, there have been 0 failures
Many reasons, including your hosting provider going down.
At that point you'd have to create and manage a cluster.
You have to update servers, etc. etc. and if you count the hours is many times more than working locally and wait a couple of hours until technicians at GitHub fix the problem for you.
Also, most people don't need to provide access to hundred of thousands of users so they won't ever need a cluster of Git servers.[1] (Some bloated UI like GitLab may need more computing to host even for a moderate amount of users, though).
Self-hosting Git is easy. Besides power failures there is not much reason this could go down if you don't help with that actively. But if you don't touch it besides OS updates it can run 24h a day for many years without any effort. (Biggest issue is backup actually, but you have to think about that point anyway if you run something on your own).
Not sure why you're being downvoted; I absolutely agree. For a smallish project, especially made up of volunteers, free time spent toward maintaining infra is time not spent on working on your project.
For larger projects where you have the resources to have dedicated infra people, I guess it depends.
Surely it can't be a coincidence that Github is down every other week after the Microsoft acquisition? Is Microsoft interfering too much? Or did the core technical expertise leave for other greener pastures in Microsoft or outside?