GitHub with degraded performance for Git Operations | Hacker News Reader

GitHub with degraded performance for Git Operations

githubstatus.com

26 pointsnzach12 comments

This is one of the reasons why my MaraDNS .git/config looks like this:

  [remote "origin"]
          url = git@github.com:samboy/MaraDNS.git
          fetch = +refs/heads/*:refs/remotes/origin/*
  [remote "sourcehut"]
          url = git@git.sr.ht:~samiam/MaraDNS
  [remote "gitlab"]
          url = git@gitlab.com:maradns/maradns.git
  [remote "bitbucket"]
          url = git@bitbucket.org:maradns/maradns.git
  [remote "sourceforge"]
          url = ssh://samboy@git.code.sf.net/p/maradns-git/code

The nice thing about Git is that it’s a distributed system, so code is easily mirrored.

However more and more development features get locked into vendor specific implementations, like testing and building using Gitlab CI/CD or Github Actions, security evaluation (eg: dependabot) and issue management workflows that required bots and the Github API. It's easy enough to host your code on a mirror, even a static http would suffice if needed, but getting your release out the door reliably is getting harder.

> like testing and building using Gitlab CI/CD

Imo that's overstated. Sure, there's always some vendor-specific configuration needed, but that should be dwarfed by the vendor-neutral setup, after all you also need something to run tests locally.

> ... after all you also need something to run tests locally.

You'd think so but for many projects contributors rely entirely on the CI system.

For huge projects that sounds like a recipe for slowing down iteration speed.

Why waste time building your own testing scripts when you can copy paste a few lines of YAML and be done.

That is very true, and I do my utmost to avoid any kind of vendor lock in.

Testing is done in a Docker container, so the CI/CD pipeline is available in a Dockerfile and the scripts the Dockerfile imports in to the testing container. In my case: https://github.com/samboy/MaraDNS/tree/master/Docker-stuff

Bug reports and support requests are handled using Github, mainly because that’s what is widely used in the industry right now, but bugs actually fixed are usually described in Git commits, where the information can easily be mirrored.

This is not a major problem if you push to all mirrors. E.g. if you're using Bitbucket CI, but also mirror your git repo in github, gitlab (as GP did) then you can just push to everyone and that will automatically trigger bitbucket CI, as well github CI (if you want to switch in the future). Of course, you'll have to maintain each CI manifest separately.

> Of course, you'll have to maintain each CI manifest separately.

Not just the manifest, the way your entire project interacts with the CI ecosystem. Which in an ideal world would be no problem, but in practice comes down to a lot of implementation specific details per environment.

How do you keep the different remotes in sync? Manual pushes?

A shell script which pushes everything everywhere in one command. Two git commands per server: One to push the code, and one to push the tags.

Looks like GitHub and GitLab both having problems today! Latter had issues with gitlab runners.

Reply on news.ycombinator.com