5 ms·

GitHub with degraded performance for Git Operations

26 points by nzach 6y ago

strenholme 6y ago
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.
- aequitas 6y ago
  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.
  - the8472 6y ago
    > 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.
    - koolba 6y ago
      > ... 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.
      - the8472 6y ago
        For huge projects that sounds like a recipe for slowing down iteration speed.
    - aequitas 6y ago
      Why waste time building your own testing scripts when you can copy paste a few lines of YAML and be done.
  - gnulinux 6y ago
    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.
    - aequitas 6y ago
      > 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.
  - strenholme 6y ago
    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 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.
- arusahni 6y ago
  How do you keep the different remotes in sync? Manual pushes?
  - strenholme 6y ago
    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.
wdb 6y ago
Looks like GitHub and GitLab both having problems today! Latter had issues with gitlab runners.

26 points by nzach 6y ago

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.

aequitas 6y ago
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.
- the8472 6y ago
  > 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.
  - koolba 6y ago
    > ... 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.
    - the8472 6y ago
      For huge projects that sounds like a recipe for slowing down iteration speed.
  - aequitas 6y ago
    Why waste time building your own testing scripts when you can copy paste a few lines of YAML and be done.
- gnulinux 6y ago
  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.
  - aequitas 6y ago
    > 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.
- strenholme 6y ago
  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 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.
arusahni 6y ago
How do you keep the different remotes in sync? Manual pushes?
- strenholme 6y ago
  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.

wdb 6y ago

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