从github迁移到gitee和以coding为基础的的全链路devops

前言

文章的标题起的比较长，实际上这篇文章将以我的hugo-blog项目为例，讲述一下我将代码提交到github，然后自动同步到gitee，再根据gitee的webhook通过coding的持续集成部署的整个过程。

感谢github、gitee的给我们个人开发者提供足够的资源来完成这一系列的数据存储过程，也感谢coding提供的在我认为目前足够使用的持续集成功能，关键是这整个过程都是不需要付费的，需要的是灵快的小脑筋以及网上前人的经验罢了（文章中会用一些英文单词，避免敏感词汇，敬请原谅）。

为什么迁移

事情的起因由俄乌战争引起，我认为没有战争是正义或者邪恶的，因为史诗是由胜利者书写的。

一直以来秉承一个原则：技术是自由的，它不能也不应该掺和到politics中去。

然而真实的情况是：技术必须与politics共存，它是在保证politics下才有的产物。

从这次俄乌战争中就可以看出来，以USA为首的西方国家彻底粉碎了技术是自由的谎言，甚至开源也不是自由的，由人主导的所谓的开源并非自由，从React到Github等一系列国外的开源软件的官网就能看出来很多现实：当我们的国家发生战争时，甚至是收复TW时，我们
将受到从金融、政治、外交、贸易、技术等一系列的和不能预知的威胁。

由此，为保障个人的权益，我决定将自己的代码库逐渐迁移到gitee中来，以预防未来可能发生的某些事情。

迁移的步骤

得益于github和gitee的用户群体都同样的大，绝大部分的坑都已经被前人趟过，我们只要稍加整理就好了。

从github迁移到gitee主要分为两步走：

• 将github的所有个人仓库全量迁移到gitee
• 将github的相关代码提交使用自动化的方式提交到gitee，保持仓库同步

以上的方案是不是很熟悉：完全就是数据库的数据热迁移步骤。下面我将详细说明以上两个步骤的具体情况：

数据仓库的全量迁移

感谢gitee提供的数据全量迁移功能，让我如此没有障碍的快速进行数据迁移，不得不说软件国产化做的越来越好，越来越贴近中国人的使用习惯。

1. 先登录到gitee进入主页，点击+号，然后可以看到从 GitHub / GitLab 导入仓库 按钮，如果没有授权及时授权,如图:
2. 进入菜单以后，可以看到你的github仓库列表（及时授权），然后选择你要导入的仓库导入就可以了，这样就完成了数据的全量迁移过程，非常简单。如图：

数据仓库的增量同步

全量迁移进行的非常顺利，接下来是对你需要经常写入的仓库进行数据的增量同步了，可以慢慢来，先将关键步骤记录下来，然后逐步逐个迁移，这样能将大量的工作分散开来。

迁移的技术方案：使用github的actions将当前仓库的提交记录同步到gitee中，个人免费版每个月有2000分钟的actions使用时间，相对来说还是比较富余的，大概1-2分钟可以同步一次commit，能同步一千来个commit，基本上够用。

迁移的步骤：

1. 准备github和gitee需要的秘钥，例如github和gitee对应的专用ssh秘钥、gitee的个人token、gitee的用户名
2. 编写github action的action.yml文件，按照实际情况进行跳转，我使用的是: Yikun/hub-mirror-action，一点开进去就是对应的说明介绍，我就不作多说
3. 提交commit 查看对应的gitee仓库是否更新到了最新的commit

需要注意的点：

• 我在action中拉取代码和提交代码都使用的是ssh方式，所以需要自己创建一对ssh秘钥，可以点击此处查看教程，此时github、gitee都需要配置这个ssh公钥。
• 在此过程中，如果是新创建的仓库需要同步，可以不在gitee那创建对应的仓库，action会自动创建，此时需要gitee的token，可以点击此处生成token（实测发现gitee的企业版有坑，注意）。
• 注意源仓库（github）对应的用户属性，设置src_account_type为user or org ，目标仓库（gitee）的参数是dst_account_type ，设置也同样如此。
• 将GITEE_PRIVATE_KEY、GITEE_TOKEN 、GITEE_USER 都配置到github的Actions secrets中去,然后再编写如下所示的action。

配置Actions secrets

创建github action 入口

对应的yml文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

# This is a basic workflow to help you get started with Actions

name: CI

# Controls when the workflow will run
on:
  # Triggers the workflow on push or pull request events but only for the main branch
  push:
    branches: [ main ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  repo-sync:
    env:
      dst_key: ${{ secrets.GITEE_PRIVATE_KEY }}
      dst_token: ${{ secrets.GITEE_TOKEN }}
      gitee_user: ${{ secrets.GITEE_USER }}
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          persist-credentials: false

      - name: sync github 2 gitee
        uses: Yikun/hub-mirror-action@master
        if: env.dst_key && env.dst_token && env.gitee_user
        with:
          # 必选，需要同步的 Github 用户（源）
          src: 'github/${{ github.repository_owner }}'
          # 必选，需要同步到的 Gitee 用户（目的）
          dst: 'gitee/${{ secrets.GITEE_USER }}'
          # 必选，Gitee公钥对应的私钥，https://gitee.com/profile/sshkeys
          dst_key: ${{ secrets.GITEE_PRIVATE_KEY }}
          # 必选，Gitee对应的用于创建仓库的token，https://gitee.com/profile/personal_access_tokens
          dst_token:  ${{ secrets.GITEE_TOKEN }}
          # 如果是组织，指定组织即可，默认为用户 user
          # account_type: org
          # 直接取当前项目的仓库名
          static_list: ${{ github.event.repository.name }}
          #启用git push -f强制同步，注意：开启后，会强制覆盖目的端仓库。
          clone_style: ssh
          #默认为https，可以设置为ssh或者https。当设置为ssh时，你需要将dst_key所对应的公钥同时配置到源端和目的端
          force_update: true
          #配置cache
          cache_path: /github/workspace/hub-mirror-cache
					#源账户的类型：user or org
          src_account_type: user
					#目标账户的类型：user or org
          dst_account_type: org

直接按照以上配置进行修改即可，开箱即用，配置好了之后，可以提交一条commit 试试效果，job执行结果如下：

查看源仓库和目标仓库的记录是否对应

检查一下源仓库（github）和目标仓库（gitee）对应的提交记录是否对应，如果对应上了就没啥问题，不然就再看看actions的执行情况。

到这就完成了从github到gitee的迁移过程了，标准的数据库数据迁移做法：全量迁移+增量同步，如果有啥情况，随时可以无损迁移到gitee。

codng的devops

其实从github迁移到gitee不仅仅是代码数据库的迁移，还有后面的一系列的devops对应的地址改变，我这边主要就是在coding的持续集成,由于我的Jenkinsfile全部都是写在代码仓库里的，这时候切换就非常方便了，直接将对应的代码源从github切换成gitee的同名仓库即可，基本没有代价。

可能会有人问gitee也有对应的持续集成 gitee go 为啥不直接在gitee中生态圈使用，主要还是因为不能和coding一样我直接在自己的主机上执行任务，这样就不计算它的免费时间了，而且coding每个月会给1000分钟的免费时间，基本上也是用不完的。（主要是省钱和合理资源利用）。

直接将github的源代码仓库修改为gitee：

如果有自有云主机，可以配置在coding的资源池中使用，这样还不占用coding的免费时间，达到资源合理利用的目的

其实从github迁移到gitee 还有一层大的好处：不需要考虑你的国内云服务器拉不下来github代码的问题了，我的云主机十次有九次拉不下来github的代码，所以我一直使用coding自带的资源池。

另外一部分还有就是如何使用coding的持续集成功能部署hugo 项目，我会出一篇文章详细说明。

结果和想法

有些事想想觉得还挺费劲，但是一旦深入了解后做起来，发现还是挺简单，有时候就需要突破思维定势，你理解的难是建立在你固有的思维体系中的，如果要说难，先详细的去了解过整个过程后再去说难。

迁移和部署都出乎我想象的顺利，整个过程几个小时就完成了，支持重要的软件国产化，自有化，这样才能不被卡脖子。只要你足够强大，那么别人的制裁就只是个笑话了。