The end of an era: goodbye, GitHub

We all knew that Microsoft would destroy GitHub. Well, I hope we all knew. I knew it too, but somehow, I thought: it doesn’t matter. Maybe they’ll add some commercial features, maybe they’ll force some integration over VSCode or Visual Studio, but anyway, I didn’t think, at the time, that they’ll be able to make something really bad about it.

This ends now.

Microsoft (I’ll not use GitHub anymore here. I’ll keep GitHub for Atom, probably, but that’s how far I’m willing to go) decided that “public repos are reusable pieces of software” regardless of license, with their “Copilot” product. Yes, people are saying that’s legal, fair trade, blah blah blah. I don’t buy it, and I believe it’s only because it’s Microsoft that they are speaking like this. Every other system that inputs <copyrighted-content> and outputs <content>, when the input and output are the same “kind” (music, painting, code, poetry) needs to be aware of the original license, and that’s final. In fact, every tool that tried to do this in the past WAS victim of copyright strikes – so why Microsoft is not? In fact, there’s public code that’s not open source on Microsoft’s servers. If they are so sure that it’s not a “derivative work”, why didn’t they train their ML with private repositories? With Microsoft’s own private code? The answer is obvious – only the fool don’t want to see.

Anyway, I’ll be removing all code from Microsoft starting now. Unfortunately, there are issues to code cooperation and other things if I decide to self-host a solution, so until Gitea allows for federated content, I’ll got with Gitlab. I’ll start with Chlorine, Clover, and similar projects like REPL-Tooling, Duck-REPLed and Vision. Then, maybe I’ll start moving things on demand (after all, all code that EXIST today was slurped by Microsoft already, so why should I bother removing the damage that already was done). So, here I’ll try to document my process:

The complicated: CI

I love CircleCI. I really do. But the problem is that it does not allow for custom VCS repositories. I’ll probably have to move CIs in the future, but for now, I tried to use GitLab CI. It didn’t work.

Well, to be more precise, it failed miserably. The first bug I found made impossible to run the CI with docker on my local machine. It was open 11 months ago, and still not fixed. I tried to rollback to the last working version, and it ALSO failed – somehow, it seems that docker wants to mount /tmp on my host (WHY?) and this breaks X11 support inside the container I think – I didn’t try to debug too deeply because the tests also fail on the cloud runners, and in this case, I have no idea why: I can’t debug, I can’t SSH into the container, I can’t run the job that fails locally (because, well, runners don’t work, and also, some of my jobs cache info, and I need to propagate that cache forward, and the GitLab runner DON’T PROPAGATE if I’m outside the cloud). So… no luck here.

What I did was to mirror my code to BitBucket, and then use CircleCI. The mirror from GitLab ALSO gave me problems, because sometimes it doesn’t mirror because it says that “the refs diverged” (spoiler alert: they did not. I almost never force-push nor squase/rebase commits). That’s, indeed, one of the reasons that, in the future, I’ll probably try a self-hosted Gitea… and also because I want to check some specific things.

I also added a API Token to Gitlab, so every job in the workflow from CircleCI will update the commit correctly. The experience is that my MR (not PR as everyone else calls it) will now have the status of the CircleCI so I can click it, see if it’s working, and have a fast~ish feedback when things go wrong. If you think that the experience on this was sub-optimal… well, I don’t blame you. It was – Gitlab sometimes puts the status inside their “pipelines” view, so you sometimes have to click multiple places to go to CircleCI, but well, it works for now. On the CircleCI, I just had to add:

prepost: &prepost
  context: org-global
  pre-steps:
    - run: 'curl --request POST --header "PRIVATE-TOKEN: $GITLAB_TOKEN" "https://gitlab.com/api/v4/projects/<my-proj>/statuses/$CIRCLE_SHA1?state=running&name=$CIRCLE_JOB&target_url=$CIRCLE_BUILD_URL"'
  post-steps:
    - run:
        command: 'curl --request POST --header "PRIVATE-TOKEN: $GITLAB_TOKEN" "https://gitlab.com/api/v4/projects/<my-proj>/statuses/$CIRCLE_SHA1?state=success&name=$CIRCLE_JOB&target_url=$CIRCLE_BUILD_URL"'
        when: on_success
    - run:
        command: 'curl --request POST --header "PRIVATE-TOKEN: $GITLAB_TOKEN" "https://gitlab.com/api/v4/projects/<my-proj>/statuses/$CIRCLE_SHA1?state=failed&name=$CIRCLE_JOB&target_url=$CIRCLE_BUILD_URL"'
        when: on_fail

workflows:
  version: 2
  default-workflow:
    jobs:
      - test:
          <<: *prepost
      #....
      - publish:
          <<: *prepost

And then things work. Please notice that I don’t have to URL-quote the CIRCLE_CI_BUILD_URL var, but I do have to quote <my-proj>, so if you want to use this config, be aware of that.

Next Steps

I’ll see how things work from here. Probably I’ll remove CircleCI in the future and maybe self-host a CI server (the problem: I do want something that uses docker, and allows me to cache things without too much moving parts. It would also be GREAT if I could spin-up a DigitalOcean/ScaleWay machine to start the build, and then turn down because that could allow me to cut costs, but I’l see) and Gitea (mostly because it’s the closest to be federated, it’s simpler, easier on the eyes and on the resources too). The reason for self-host anything is obvious:

I’m tired of companies becoming evil, and using my info, my work, to become stupidly rich (or, in this case, richer). Microsoft didn’t need that. But, well, a company with a history of shady practices, what should I expect? The fool was I, to think that they would somehow be reasonable.