[HN Gopher] GitHub with degraded performance for Git Operations
___________________________________________________________________
GitHub with degraded performance for Git Operations
Author : nzach
Score : 24 points
Date : 2021-02-24 19:34 UTC (3 hours ago)
(HTM) web link (www.githubstatus.com)
(TXT) w3m dump (www.githubstatus.com)
| strenholme wrote:
| 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.
| arusahni wrote:
| How do you keep the different remotes in sync? Manual pushes?
| strenholme wrote:
| 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.
| aequitas wrote:
| 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 wrote:
| > 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 wrote:
| > ... 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.
| aequitas wrote:
| Why waste time building your own testing scripts when you
| can copy paste a few lines of YAML and be done.
| gnulinux wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| wdb wrote:
| Looks like GitHub and GitLab both having problems today! Latter
| had issues with gitlab runners.
___________________________________________________________________
(page generated 2021-02-24 23:02 UTC)