Chuyển từ GitHub sang Codeberg, cách dành cho người lười

 (unterwaditzer.net)
1 điểm bởi GN⁺ 26 ngày trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Khi chuyển một số dự án từ GitHub sang Codeberg, bài viết tổng hợp cách bắt đầu quá trình chuyển đổi với ít công sức nhất
  • Thông qua tính năng nhập kho lưu trữ của Codeberg, có thể chuyển đầy đủ cả issue, PR và release, đồng thời giao diện và quy trình làm việc tương tự GitHub
  • Lưu trữ trang tĩnh có thể được thay thế bằng codeberg.page, và cũng có các lựa chọn khác như grebedoc.dev hay statichost.eu
  • Khó khăn lớn nhất là thiết lập môi trường CI, vì phải từ bỏ runner macOS và dung lượng chạy miễn phí của GitHub, nhưng có thể thay bằng Forgejo Actions hoặc Woodpecker CI
  • Sau khi chuyển, có thể giữ kho GitHub ở trạng thái lưu trữ chỉ đọc hoặc mirror, để không cắt đứt hoàn toàn kết nối với hệ sinh thái mã nguồn mở

Quá trình chuyển từ GitHub sang Codeberg

  • Dựa trên trải nghiệm bắt đầu chuyển một số kho lưu trữ từ GitHub sang Codeberg, bài viết giải thích mức độ khó và sự thuận tiện của quá trình migration thực tế
    • Tác giả từng trì hoãn vì nghĩ Codeberg chưa đủ sẵn sàng, nhưng tùy dự án thì việc chuyển có thể đơn giản hơn mong đợi
    • Mục tiêu không phải là thiết lập hoàn hảo mà là tìm ra cách dễ nhất để bắt đầu việc chuyển đổi

  • Chuyển kho lưu trữ và issue

    • Codeberg cung cấp tính năng import kho GitHub, cho phép chuyển cả issue, PR, release và các artifact liên quan
      • Trong quá trình này, số issue, nhãn và thông tin tác giả được giữ nguyên
      • Giao diện của Codeberg gần như giống GitHub, mang lại trải nghiệm đơn giản hơn nhiều so với các thủ tục phức tạp thường cần khi chuyển từ tracker khác sang GitHub

  • Lưu trữ trang tĩnh

    • Nếu đang dùng GitHub Pages, có thể thay bằng codeberg.page
      • Dù không có cam kết mức độ sẵn sàng (SLO) chính thức, tác giả nói rằng trên thực tế chưa từng gặp downtime
      • Cách hoạt động là push HTML lên một branch, với cấu trúc tương tự GitHub Pages
      • Ngoài ra cũng có thể dùng grebedoc.dev hoặc statichost.eu

  • Khó khăn của môi trường CI (tích hợp liên tục)

    • Phần khó nhất trong quá trình migration là thiết lập môi trường CI
      • GitHub cung cấp runner macOS miễn phí và dung lượng chạy không giới hạn cho kho công khai, nhưng khi sang Codeberg thì phải chấp nhận từ bỏ các lợi ích này
      • Có thể giải quyết bằng cách tận dụng cross-compile theo từng ngôn ngữ và tự host runner cho Forgejo Actions

    • Forgejo Actions vs Woodpecker CI

      • Trên Codeberg, Woodpecker CI ổn định hơn, nhưng Forgejo Actions mang lại môi trường quen thuộc hơn cho người dùng GitHub Actions
      • Giao diện và cú pháp YAML gần như giống hệt, nên phần lớn workflow GitHub Actions hiện có vẫn chạy nguyên trạng
      • Ví dụ, phần dùng uses: dtolnay/rust-toolchain trong GitHub Actions trên Forgejo Actions chỉ cần đổi thành uses: https://github.com/dtolnay/rust-toolchain
      • Tài liệu Forgejo Actions hiện tại của Codeberg chưa được cập nhật mới nhất, và đã có PR liên quan

    • Khi cần runner macOS

      • Nếu thực sự cần build trên macOS, có thể tiếp tục dùng GitHub Actions và mirror commit từ kho Codeberg sang GitHub
      • Có thể cấu hình để Forgejo Actions polling GitHub API và đồng bộ trạng thái CI về Codeberg
      • Tác giả cũng đã thử các dịch vụ CI khác có hỗ trợ build macOS, nhưng việc tích hợp với Codeberg không đơn giản bằng GitHub Actions

  • Cách xử lý kho GitHub

    • Sau khi chuyển xong, kho GitHub được sửa README rồi đưa vào trạng thái lưu trữ
      • Cũng có thể cấu hình để push commit từ Codeberg sang GitHub, nhưng khi đó người dùng vẫn có thể tạo PR và bình luận vào issue
      • Một số dự án tắt tính năng issue trên kho GitHub, nhưng làm vậy thì toàn bộ issue sẽ biến mất dưới dạng 404 và không thể tắt PR
      • Ví dụ, kho libvirt/libvirt dùng một GitHub Action tự động đóng tất cả PR
    • Cách tiếp cận này có thể gây ảnh hưởng tiêu cực đến việc tự host và toàn bộ hệ sinh thái mã nguồn mở
      • Người dùng có thể mất động lực cải thiện tối ưu build hoặc tần suất tải xuống file phát hành
      • Trong giai đoạn chuyển tiếp, cũng có thể cân nhắc duy trì mirror chỉ đọc hoặc tiếp tục dùng song song GitHub Pages và Actions

Bài viết liên quan

1 bình luận

 
GN⁺ 26 ngày trước
Ý kiến trên Hacker News

  • Tôi không ghét Codeberg, nhưng nó không phải bản thay thế hoàn chỉnh cho GitHub
    Có khá nhiều hạn chế nếu muốn đưa kho mã cá nhân hoặc script thử nghiệm lên, và repo riêng tư bị giới hạn ở 100MB
    Cũng không thể host homepage như GitHub Pages. Với các nhu cầu như vậy, giải pháp thực tế hơn là tự host Forgejo
    Nội dung liên quan được tổng hợp khá rõ trong Codeberg FAQ

    • Codeberg cũng có thể host homepage thông qua tính năng Codeberg Pages
    • Tôi cũng đang vận hành website của mình trên Codeberg Pages. Thông tin ở trên là sai → tài liệu Codeberg Pages
    • Tôi khó đồng ý với ý “tự vận hành git server là gánh nặng”. Nếu chỉ cần một chỗ để push code thì một SSH server là đủ
    • Dự án Code Storage do Pierre tạo ra khá thú vị như một git server dạng API giúp giảm gánh nặng vận hành
    • (Nhân tiện quảng bá) tôi đang phát triển một lựa chọn thay thế GitHub tên là Monohub. Có repo riêng tư mặc định và hỗ trợ PR. Ví dụ repo công khai

  • Lý do tôi đưa các dự án OSS lên GitHub rất đơn giản — cộng đồng ở đó
    Nếu chỉ cần đăng code thì tôi tự host trực tiếp bằng SSH hoặc SFTP

    • Việc cộng đồng chỉ ở lại GitHub là một kiểu con gà hay quả trứng có trước. Rốt cuộc phải có ai đó chuyển sang nền tảng khác trước thì hệ sinh thái mới dịch chuyển
      Tôi chỉ đăng lên instance Gitea cá nhân của mình và không bận tâm đến star hay quảng bá
    • Những người còn ở lại GitHub chỉ là cộng đồng FOSS chấp nhận sự phụ thuộc đóng. Ngược lại, chính các chính sách của GitHub đang khiến mọi người rời đi
    • Một số dự án thậm chí không thể tham gia nếu không có tài khoản GitHub. Ví dụ vấn đề của crates.io đã 10 năm chưa được giải quyết, và Reservoir của Lean yêu cầu ít nhất 2 star trên GitHub. Điều này trông như sự phụ thuộc ngày càng mạnh vào Microsoft
    • GitHub cung cấp rất nhiều tài nguyên CI miễn phí. Đặc biệt gần như không có lựa chọn thay thế cho macOS runner. Nhờ vậy có thể test trên nhiều môi trường khác nhau
    • Tôi cũng bắt đầu host Git trên homeserver để rời khỏi GitHub, nhưng cảm giác dopamine khi push commit như trước đã biến mất. Có cảm giác sức hấp dẫn của open source giảm đi khi nó bị thương mại hóa

  • Tôi đang quản lý mọi dự án cá nhân bằng Forgejo tự host. Hoàn toàn không nhớ GitHub
    Có thể giới hạn truy cập bằng Tailscale để chặn AI crawler

    • Tôi cũng tự vận hành Forgejo vài năm nay. Thậm chí còn viết hướng dẫn cài đặt và gần đây chuyển sang 2 chiếc Raspberry Pi ở Hetzner. Nhanh và ổn định hơn GitHub
    • Trước đây tôi dùng GitLab, nhưng Forgejo là single binary Go nhẹ hơn rất nhiều nên tiêu tốn ít tài nguyên hơn. Có thể chạy dễ dàng bằng Docker, và cũng rất vui khi tự hack thêm tính năng
    • Tôi cài Forgejo khi việc tạo tài khoản agent trên GitHub bị chặn, và chỉ trong 15 phút đã tự thêm được tính năng “ẩn file đã Viewed” trong lúc review PR
    • Gần đây nhiều dự án OSS lớn chuyển sang Forgejo nên tôi cũng đi theo, và đến giờ thì rất hài lòng
    • Tôi cũng cài Forgejo runner bằng Docker để chạy CI. Nó có registry riêng nên tôi phát hành ứng dụng dưới dạng Docker image

  • Có lẽ việc đánh giá các lựa chọn thay thế GitHub sẽ ngày càng quan trọng
    Nhưng GitHub đã gần như đặt ra tiêu chuẩn CI và build đa kiến trúc, nên các lựa chọn thay thế do cộng đồng dẫn dắt rất khó cạnh tranh

    • CI không nhất thiết phải phụ thuộc vào GitHub. Thực ra đa số CI chỉ là trình chạy lệnh đơn giản. Với các team nhỏ thì ngay cả không có CI cũng vẫn vận hành ổn
    • Tôi không hiểu vì sao tự vận hành CI lại bị xem là phi lý. Tách repo và CI ra cũng chẳng có vấn đề gì
    • Điều quan trọng với tôi không phải CI mà là trải nghiệm PR và review code. GitHub vẫn còn rất nhiều chỗ bất tiện, và hệ thống issue thì như đang ở mức của 20 năm trước
    • Những lớp tập trung hóa kiểu này rốt cuộc xuất phát từ ham muốn kiểm soát. Với workflow phân tán, lấy local làm trung tâm, vẫn có thể phát triển rất vui vẻ

  • GitHub cung cấp nhiều thứ “miễn phí”, nhưng đổi lại dữ liệu có khả năng bị thu thập và dùng để huấn luyện
    Codeberg không hỗ trợ repo riêng tư, nên cũng không thể ngăn Copilot quét repo công khai
    Theo Codeberg FAQ, nếu cần dự án riêng tư thì họ khuyến nghị tự host Forgejo

    • Nhưng repo Codeberg của tôi đang được đặt ở chế độ riêng tư. Có vẻ không phải hoàn toàn là không thể

  • Công ty chúng tôi đã chuyển hoàn toàn từ GitHub sang GitLab tự host
    Đặt sau Tailscale nên không phải lo gánh nặng SSO, còn CI runner thì chạy trên EKS và cụm GPU. Tôi có thể giúp những ai đang cân nhắc một đợt chuyển đổi tương tự

    • Không biết bên bạn có cân nhắc Forgejo không. GitLab mạnh về CI/CD cấp doanh nghiệp, nhưng với dự án nhỏ thì Forgejo có vẻ là lựa chọn nhẹ hơn
    • Tôi cũng tò mò không biết GitLab tự host có hỗ trợ các tính năng như tự động cấp phát người dùng (SCIM) hay không

  • Chỉ nói “hãy thay thế GitHub” thì không có nhiều ý nghĩa. Cần thói quen mới và đề xuất giá trị mới
    Giống như GitHub từng thay thế SourceForge, nền tảng thế hệ tiếp theo phải kết nối việc viết code và cộng tác theo thời gian thực
    Ví dụ, nó có thể trở thành một cấu trúc mà mỗi prompt đều tạo ra một commit, kiểu như Google Docs

    • Nhưng yếu tố địa chính trị cũng rất lớn. Ở châu Âu và nhiều nơi khác đang có xu hướng tránh phụ thuộc vào công nghệ Mỹ
    • Gần đây tranh cãi quanh Copilot đã làm lung lay niềm tin, tạo ra làn sóng muốn rời GitHub
    • Với tôi, điều quan trọng không chỉ là tính năng mà còn là độ sẵn sàng (uptime). Dạo này GitHub còn chưa đạt nổi 99%

  • Codeberg thì lý tưởng, nhưng thực tế lại có vấn đề ổn định đáng kể
    Vì vận hành mà không dùng Cloudflare nên dễ tổn thương trước tấn công DDoS và downtime xảy ra khá thường xuyên. Khi đang phát triển mà không truy cập được remote repo thì thực sự rất khó chịu

    • Tôi dùng GitHub hay Codeberg đơn thuần như nơi chia sẻ code bất đồng bộ. Dù remote có chết thì vẫn phải làm việc được ở local
    • Tôi không thích Cloudflare, nhưng thực tế thì nó gần như bắt buộc để phòng thủ trước bot traffic và tấn công. Các dịch vụ thay thế thậm chí còn bị chặn thường xuyên hơn hoặc kém ổn định hơn. Tôi cảm nhận rất rõ khoảng cách giữa nguyên tắc và thực tế
    • Nhìn vào trình theo dõi uptime của GitHub thì 90 ngày gần đây chỉ ở mức 90%. Ngược lại Codeberg còn ổn định hơn
    • Git server cá nhân của tôi cũng bị giảm hiệu năng vì AI crawler cào quét bừa bãi. Cuối cùng tôi phải chặn toàn bộ IP của các công ty lớn
    • Cốt lõi của git là tính phân tán. Dù remote có chết thì local vẫn phải có bản mới nhất

  • Từ sau khi Microsoft mua lại, tôi gần như không dùng GitHub nữa. Tôi lại thích workflow email đơn giản của Sourcehut hơn
    Tôi cũng nghĩ CI chỉ cần ở mức dựa trên các lệnh có thể chạy được trên local là đủ

  • Kho lưu trữ mã về bản chất nên có cấu trúc phân tán/liên hợp
    Nhờ cơ chế chữ ký mật mã (GPG/SSH) của git, có thể tách riêng độ tin cậy của kho lưu trữ và độ tin cậy của commit
    Chỉ cần để phần máy chủ trung tâm lo key server và quản lý namespace, còn lại thì phân tán là được

    • Radicle chính là dự án nhắm tới git hosting phân tán như vậy
    • Nhưng phần lớn developer lại không quản lý khóa ký cho tử tế
    • Vì lý do đó mà các giao thức liên hợp như Tangled hay ForgeFed đang được tích hợp vào Forgejo
    • git-bug cũng là một cách tiếp cận thú vị. Tôi chưa dùng thử nhưng thấy có tiềm năng