I have a library that has over 2 Million downloads in pip. How do you switch from github to codeberg (or any other git)? I just dont want to break things for everyone :)
You can start by moving your development workflows (pull requests, issue tracking, etc.) to something like codeberg. You can continue publishing your PyPI package from Github by just pushing your code from codeberg to Github.
Eventually you can also move the publishing pipeline over as well. I don’t know how complicated your library is, of course, but in simplest cases it’s a matter of rewriting a config file in a slightly different way.
Next I gotta update the readme on GitHub telling everyone that I’m going to move to Codeberg. I’ll let that sit for a few months.
Also, I gotta update consumers like homebrew to consume from Codeberg instead.
I was gonna close/merge any open PRs on GitHub.
Issues, I’m not totally sure about. I thought I read there was a way to migrate those. Although, I’m kiiinda ok with starting fresh… not totally sure this part needs more thought.
Once the Codeberg repo is ready, I’ll make the GitHub repo read-only, with the readme pointing to Codeberg.
Way, way, way down the line, I’d consider deleting the GitHub repo (and finally my account).
I’m OK with breaking things. I’m gonna try my hardest to not break stuff, but I’m not going to let the fear of breaking stuff prevent me from getting on ShitHub by Macroslop.
I have a library that has over 2 Million downloads in pip. How do you switch from github to codeberg (or any other git)? I just dont want to break things for everyone :)
You can start by moving your development workflows (pull requests, issue tracking, etc.) to something like codeberg. You can continue publishing your PyPI package from Github by just pushing your code from codeberg to Github.
Eventually you can also move the publishing pipeline over as well. I don’t know how complicated your library is, of course, but in simplest cases it’s a matter of rewriting a config file in a slightly different way.
I mean, if Zig and Guix can do it. It’s possible.
I’m in a similar boat. So far:
Next I gotta update the readme on GitHub telling everyone that I’m going to move to Codeberg. I’ll let that sit for a few months.
Also, I gotta update consumers like homebrew to consume from Codeberg instead.
I was gonna close/merge any open PRs on GitHub.
Issues, I’m not totally sure about. I thought I read there was a way to migrate those. Although, I’m kiiinda ok with starting fresh… not totally sure this part needs more thought.
Once the Codeberg repo is ready, I’ll make the GitHub repo read-only, with the readme pointing to Codeberg.
Way, way, way down the line, I’d consider deleting the GitHub repo (and finally my account).
I’m OK with breaking things. I’m gonna try my hardest to not break stuff, but I’m not going to let the fear of breaking stuff prevent me from getting on ShitHub by Macroslop.
How did you get the CI working in codeberg? last time I checked, you had to get permission to do so(?). I would love to switch when I have time.
You do have to ask for permission. https://docs.codeberg.org/ci/
Asking permission involves creating an issue on the
Codeberg-e.V./requestsrepo: https://codeberg.org/Codeberg-e.V./requests/issues/new?template=ISSUE_TEMPLATE%2FWoodpecker-CI.yamlHere’s an example issue asking permission for CI: https://codeberg.org/Codeberg-e.V./requests/issues/1663
They get back to you fairly quickly. I think the main thing they check for is if your project is FOSS. They don’t seem very strict otherwise.
After you get permission, you can go to https://ci.codeberg.org/login to access CI.
You’ll also need to create a
.woodpeckerfolder in your repo.Woodpecker docs are here: https://woodpecker-ci.org/docs/usage/intro
# .woodpecker/my-first-workflow.yaml when: - event: push branch: main steps: - name: build image: debian commands: - echo "This is the build step" - echo "binary-data-123" > executable - name: a-test-step image: golang:1.16 commands: - echo "Testing ..." - ./executableI think you would clone the repo and continue with codeberg. Announce wherever you can, and continue any new work at the new repo.