标签归档:github

black and white penguin toy

使用 Github Action 发布 WordPress 插件

WordPress 官网的插件系统采用的是 SVN 来进行管理,如果你希望将自己的插件发布至 WordPress 官网,就必须在本地安装 SVN,不太利于项目的管理。此外,WordPress 官网提供的是一个发布系统,而非版本控制系统(只是将 SVN 用作插件管理,并不是真打算让你每一个变更都提交),因此,你还是需要使用另外的版本控制系统(比如 Git)来管理你的代码。

为了简化发布,你可以采用 GitHub Action 来完成你的插件自动发布,这样你就可以使用 Git 来开发和管理你的插件,并让 Github Action 自动进行插件的发布。

具体操作

1. 配置 Action Secrets

因为你需要使用版本控制来进行发布,以及可能存在的协作开发的场景,处于安全的考虑,你应该将你的 SVN 的信息放置在 Action Secrets 当中。

在仓库当中找到 Secrets – Actions ,新建两个 Secrets:SVN_USERNAMESVN_PASSWORD,配置上你的 SVN 账号信息,稍后将会使用你的这个账号信息来进行插件的发布

2. 创建一个 .distignore 文件

.distignore 文件可以帮助你实现忽略不需要发布到 WordPress 插件系统的文件,这样就让你的插件目录变得更加干净一些。在你的仓库根目录创建一个 .distignore 文件,并填写具体要忽略的文件,即可实现部分发布至 WordPress 插件目录。

以下是我的 Example

node_modules/
.github/
.git/
.distignore
.gitignore
package.json
package-lock.json
yarn.lock

3. 创建 Action 文件

在你的项目的 .github/workflows/ 中创建一个 publish.yml文件,并在其中添加如下代码即可。

name: Publish to WordPress Plugin Directory
on:
  push:
    tags:
    - "*"
jobs:
  tag:
    name: New tag
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master
    - name: Build # 如果没有 NPM 相关构建工作,可以去除这一步。
      run: |
        npm install
        npm run build
    - name: WordPress Plugin Deploy
      uses: 10up/action-wordpress-plugin-deploy@stable
      env:
        SVN_PASSWORD: ${{ secrets.SVN_PASSWORD }}
        SVN_USERNAME: ${{ secrets.SVN_USERNAME }}
        SLUG: wpstoreapp-spellcheck

4. 发布版本

接下来只需要执行如下操作,既可以发布版本

git add .
git commit -m 'feat: release new version'
git tag 1.0.0
git push && git push origin 1.0.0

上述代码中的 1.0.0 即为具体的版本号,可以根据你的诉求进行修改。

总结

在完成了配置后,后续你的插件发布就变得十分简单了:修改本地的 readme.txt 中的版本号,加入 changelog,并修改插件文件头中的版本,即可提交一个 commit ,添加对应的版本的 tag,然后 Push 到 Github 上,由 Github 来进行插件的发布。

而如果你是以公司/团队的形式来管理插件,也可以用类似的方式,这样虽然每个人都不掌握 SVN 的账号密码,但却可以完成插件的发布,十分方便。

CAPTCHA

Faker.js 事件中 Github 有错么?

Faker.js 事件发生后,不少人认为 GitHub 在事件的发展过程中,没有站在开发者的一边,而是站在了资本的一边,封禁了开发者 Marak 的账号,屁股歪了。

但在我看来,这个事情其实没有那么复杂。在这个事情中,GitHub 的行为是合情合理的。

在这个事件中,Github 做了两件事:

  1. 暂停了作者 Marak 的账号:注意,这里是暂停 Suspend 而不是 Delete。
  2. 在申诉后,恢复了该账号的使用:Marak 目前依然在使用自己的 GitHub 账号

这两件事都是合情合理的。接下来说说我的理由?

1. GitHub 为什么有权暂停 Marak 账号?

在所有的网站注册的时候,都会有一个“用户条款”,英文一般是 Terms of Service。这里的用户条款是一个制式合同,你继续使用该应用时,则说明你已经同意了该合同。

在 GitHub 的 Terms 中也有一些明确的描述:

GitHub has the right to suspend or terminate your access to all or any part of the Website at any time, with or without cause, with or without notice, effective immediately. GitHub reserves the right to refuse service to anyone for any reason at any time.

https://docs.github.com/en/github/site-policy/github-terms-of-service#3-github-may-terminate

GitHub 是有权暂停你的账号的。换句话说,你在注册账号时,已经授予了 Github 暂停你账号的权力。如果你不同意,可以选择不使用 GitHub。如果你同意,Github 则可以暂停你的账号。

从法律条款上来讲,GitHub 是可以封禁 Marak 的账号的,那从情理上来说呢?

Marak 在做的事情是向开源代码投毒,从平台的角度来看,完全有理由认为,这是账号遭到了恶意入侵,从这个角度来看,平台也有理由暂时封禁账号,并由账号的持有者提交信息来解封账号。

所以从情理上来讲,Github 暂时封禁 Marak 的账号也是可以理解的。

2. GitHub 为什么有权处置作者的账号和代码?这是不是侵犯了作者的著作权?

答案显然也是否定的。

著作权保护的是作者对于自己作品的处置权和分配权。作者有权不让某些平台使用自己的作品。但对于平台不使用作者的作品的 case,显然不属于著作权的保护范围。

这里我也举一个类似 Marak 的例子。假设作者 A 的书当中有不符合平台 B 调性的内容,不考虑在平台 B 上上架,则在这种情况下,作者依然无法以著作权为由来要求平台 B 上架图书。

是不是觉得很合理?如果这个很合理,那对于 Github 的例子是一样的。

灵光一闪

灵感:一个分析 Github 项目买 Star 的工具

我关注到了 Semi Design 在发布的前一天,突然骤增了 1.5K star。在我看来,这是一个不太正常的数据,因此,便觉得,应该有个工具,可以做。

功能用法描述

用户打开应用,然后输入项目地址,点击后开始分析,数据分析完成后,可以提取结果。

提取结果后,可以按照 邮箱域、公司、原创项目的数量、Follower 数量、注册时间、是否设置了个人网站等信息作为维度进行筛选,并在筛选完成后,展示相应的比重。

这个工具并不能直接评判谁是 fake user,但可以帮助你更好的按照你心目中的标准进行筛选。

当然,也可以进一步收集大家筛选的习惯,筛选出那些可能是 fake user 的习惯,并提供给用户进行参考。

部分 MVP 代码

{
  repository(owner: "arco-design", name: "arco-design") {
    stargazers(first: 100 ) {
      pageInfo {
        endCursor
        hasNextPage
        hasPreviousPage
        startCursor
      }
      edges {
        starredAt
        node {
          email
          name
          company
          repositories(first:100, isFork: false) {
            totalCount
          }
          createdAt
          updatedAt
          twitterUsername
          websiteUrl
          followers(first: 0) {
            totalCount
          }
          following(first: 0) {
            totalCount
          }
        }
      }
    }
  }
}
灵光一闪

灵感:一个基于 Github 的 Twitter 用户数据分析工具

这两天在研究 Twitter 的增长。在想有没有可能做一个开源的 Twitter 用户数据分析工具。奈何暂时没空,所以先把灵感记录下来。

特色

  1. 使用 Github 存储数据,无需另行创建数据库
  2. 项目无需服务器

特性

  1. 使用 Github Action 获取数据
  2. 使用 Github 存储数据
  3. 使用 GitHub Pages 展示数据

一些实现的思路

  1. Github Action 支持定时触发,可以设定每小时/每分钟启动一次,这个应该是一个配置参数。
  2. 数据应该是两种,一种是分块数据,按日切片/按小时切片。同时应该还有一个合并后的数据,用于 Web 展示。这部分的实现思路可以参考之前做的 opensource menu
  3. 页面应该是自动构建然后放置在 gh-pages 分支,然后可以默认访问。
  4. 页面应该可以看到数据和在数据前后的 tweet (所以需要调用多个 API)

black and white penguin toy

@action/checkout 如何抓取所有的历史记录

GitHub 的 Action Template 中默认带了一个 checkout 插件,这个插件可以实现将你的项目 Clone 到 CI 的运行环境中,从而执行各项操作。

为了提升速度,Github 在实际上实现的时候,默认会限制 depth=1,这就导致在 clone 的时候,仅 clone 一个 commit ,如果你需要依赖 git 进行操作,则需要更多的 commit 。

在具体的实现过程中,你需要做的仅仅是在配置 github action 中的 fetch-depth 选项,设置为你需要的 commit 数量。如果你需要的是所有的 commit, 则将该选项设置为 0。具体配置如下

- uses: actions/checkout@v2
        with:
          fetch-depth: 0

这样你就可以在 CI 中访问到所有的数据。

不过,这样你并不能直接执行诸如 git merge-base 这样的命令,因为你虽然将所有的数据抓取到了本地,但并没有建立相应的分支,则需要你先建立相应的分支,才能进行处理。

这个时候你可以在 action 当中新增一行,用来切换分支。

- run: git checkout x

这里的 x 是你需要操作的分支,不过你需要注意,切换过来以后,还需要重新切换回去,不然你的代码就版本不对了。

black and white penguin toy

如何使用 GitHub Action 自动部署 MKDocs

MKDocs 是一个基于 Python 写成的文档生成工具,在实际的使用过程中,我们可以借助 GitHub Action 来实现自动部署到 GitHub Pages 。

操作流程

首先,你需要先在本地生成一个 MKDocs 项目

生成后, 你可以在项目的根目录创建 GitHub Action 所需目录。

mkdir -p .github/workflows/

并创建一个配置文件 publish_docs.yml

name: Publish docs via GitHub Pages
on:
  push:
    branches:
      - main
jobs:
  build:
    name: Deploy docs
    runs-on: ubuntu-latest
    steps:
      - name: Checkout main
        uses: actions/checkout@v2
      - name: Deploy docs
        uses: mhausenblas/mkdocs-deploy-gh-pages@master
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          CONFIG_FILE: mkdocs.yml
          EXTRA_PACKAGES: build-base

创建完成后,将配置文件添加到版本控制中,并提交到 GitHub 上,就可以在你提交代码的时候,自动推送到 GitHub Pages 中。

需要注意的是,我使用的是 MKDocs 的 Material Design 主题,如果你使用的是其他主题(非自带的主题),则需要修改 EXTRA_PACKAGES 的配置。

代码解读

这个配置文件中主要是 on 和 steps 比较有学习的价值。

on:
  push:
    branches:
      - main

这段代码限制了,只有在 main 分支上,出现了 commit 的时候,才会触发这个 action 的执行,如果是其他的分支,则不会触发 action 的构建。

    steps:
      - name: Checkout main
        uses: actions/checkout@v2
      - name: Deploy docs
        uses: mhausenblas/mkdocs-deploy-gh-pages@master
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          CONFIG_FILE: mkdocs.yml
          EXTRA_PACKAGES: build-base

这里的两个 step, 第一个是 clone 出所有的代码, 第二个 step 就是我使用一个已经做好的 action mhausenblas/mkdocs-deploy-gh-pages@master,这个 action 的作用就是将 mkdocs 的文档生成并部署到 GitHub Pages 中。

这个 action 自带了 material design 的主题,执行后,会构建并推送到 GitHub Pages。如果你使用的也是这个主题就可以直接按照我的样式进行配置。如果你使用的不是这个主题,则需要将你的主题配置在 EXTRA_PACKAGES,从而让 action 在执行的时候安装相应的 package。

总结

GitHub Action 的 Marketplace 中有大量的现成 Action 可以供你使用,借助现成的 Action ,你可以非常简单的完成自己的 CI/CD 流程,非常方便。

black and white penguin toy

LCTT 从Travis CI迁移到 GitHub Action 实践

LCTT 的 CI 已经在 Travis CI 上运转了多年,一致保持着良好的使用体验。自 2019 年 Github 推出了自家的 CI 工具 Github Action 后,我们就在考虑将 CI 从 Travis-CI 迁移到 Github,以降低维护和沟通的成本,并借助于 GitHub Action Marketplace 实现更强的功能。

项目首页
项目首页

最近,因为 TravisCI 屡屡部署出错,而我们的账户因为使用的较多,已经超出了免费使用的限制,以此为契机,将 CI 从 Travis CI 迁移到 GitHub Action。

Travis CI 的提醒
Travis CI 的提醒

项目介绍

Translate Project 是 LCTT 翻译组的主要协作项目,几百位译者通过 GitHub 进行围绕开源、Linux、软件工程等领域的文章翻译,从 2013 年来,累计了大量的 Commit,致使项目下有非常多的文件。

Transalte Project 借助于 CI 帮助译者进行基本的文章格式进行检查;并定时执行命令,以进行所有的文章检查,对于超时未完成翻译的工作进行回收;对于文章的状态进行标记,生成相应的 Badge。

生成 badge
生成 badge

迁移思路

Travis CI 和 Github Action 在使用方面,其实总体差异不会太大,都是基于 YAML 文件格式来编写配置文件。不过,和 Travis CI 不同的是,Github Action 支持多个不同的配置文件,因此,你可以根据不同的场景,设定不同的配置文件,降低单个配置的文件的复杂度。

此外,由于我们的脚本中依赖了一些 Travis CI 的环境变量,也需要将其替换为 Github Action 中的相应环境变量,从而确保脚本可以运转。

改造实践

1. 分析之前的 CI 流程

我们在 TravisCI 上的 CI 配置文件如图

配置文件
配置文件

总体可以分为三块:

  1. 命令区:说明了安装阶段和执行阶段的操作有哪些
  2. 条件区:指定了这个配置文件在哪些条件下会生效
  3. 部署区:写明了构建产物如何进行部署

在命令区中,有预置的安装过程和后续的执行过程。在安装过程中,安装了一些依赖,并将当前的 pages 资源克隆到本地,以继承上一次构建生成的资料。

在条件区则指明了仅作用于 master 分支

在部署区便是将前面命令区的执行结果进行部署。

基本流程
基本流程

在实际的执行过程中,还会根据环境变量不同,决定是否要执行特定的命令,这部分在后续的改造过程中,就可以调整部署,拆分到不同的文件中。

构建流程
构建流程

2. 直译配置文件

在完成了基本的分析后,就可以建立新的 Action 配置文件了。由于基本的语法很类似,对于其中的不少内容可以进行直译。

比如,我们的配置文件在直译后,结果如下

直译后的结果
直译后的结果

直译的文件已经可以直接运行,不过,这里有很多不满足需要的地方,所以需要做一些修改。

3. 恢复 Travis CI 的环境变量

由于我们使用的 Badge 等生成脚本并非我所编写,所以在这一次的迁移中,并不打算对齐进行调整,以避免出现故障。而脚本中依赖了一些变量,需要将其重新设置出来。

Github Action 提供了一些方法,可以让你手动设置环境变量。你可以在你的构建的 step 中,加入如下代码,从而在构建环境中设定 TRAVIS_BRANCH 和 TRAVIS_EVENT_TYPE 环境变量,确保你可以使用这个环境变量。

 - <strong>name</strong>: Set ENV variables
        run: |
          echo "::set-env name=TRAVIS_BRANCH::${TRAVIS_BRANCH:-$(echo $GITHUB_REF | awk 'BEGIN { FS = "/" } ; { print $3 }')}"
          echo "::set-env name=TRAVIS_EVENT_TYPE::$(if [ "schedule" == "$" ]; then echo "cron"; else echo "$"; fi)"

此外,由于 set-env 这个方法相对比较危险,你还需要在环境变量中,开启危险函数的执行。

jobs:
  build:
    runs-on: ubuntu-latest
    env:
      ACTIONS_ALLOW_UNSECURE_COMMANDS: true

4. 拆分配置文件

Github Action 和 TravisCI 不同的一点是你可以将你的 CI文件拆分成多个文件,从而降低每一个单独的配置文件的复杂度。

根据前面对于流程的分析,可以将我们的 CI 流程拆分成三个部分:

  1. 生成 badge 文件,应当跟随每一次 commit 进行
  2. 生成 status 文件,执行时间较长,可以定期执行
  3. 根据 Pull Request 内容进行整理,做核验

则将我们的配置文件拆分成三个不同的文件

也得益于拆分开,则在 checker 中就可以免于安装一些必要的依赖,从而精简 CI 流程,提升 CI 的执行时间。

5. 测试 CI 的运行情况

在完成了配置文件的编写和拆分后,就可以进行本地的执行测试。Github Action 写完了,难免要执行一下,确保整个流程是正常的。

这个时候你可以安装工具(https://github.com/nektos/act),来在本地执行 action ,从而确认你的代码执行是正确的。

如果你是 macOS ,只需要执行 brew install act 就可以安装 act 工具,来完成 act 的安装。

安装完成 act ,就可以通过执行 act 命令来在本地执行 action ,比如,执行 act pull_request来触发 GitHub 的 Pull Request 事件

通过本地测试后,再将你的配置文件推送到 GitHub 上,进行生产环境的测试即可。

6. 移除 Travis-CI

通过上述的一些步骤,我们完成了从 Travis CI 到 GitHub Action 的迁移,此时,就可以移除项目根目录中的 .travis.yml 文件,彻底关闭 travis-ci。

7. 修改 GitHub 的 Branch 保护条件

为了确保修改符合标准,我们限制了新的 Pull Request 必须通过 CI 检查,才能合并进入 master,因此,也需要修改相应的分支保护规则,确保设定相应的保护。

一些注意事项

1. 环境变量不同

如果你依赖了环境变量,则需要进行相应的修改。或者可以像我一样,先通过 set-env 来让本地拥有临时的环境变量,后续再逐步进行迁移。

2. Action 运行依赖要注意安全

Action 执行过程中会有两个部分。action 本身流程依赖于 master,但执行过程中调用的脚本是根据 source 决定的,因此,从安全角度来看,你应当尽可能将所有的流程放在 Action 中,而不是放在你的源码目录中。

总结

通过对 TravisCI 的流程整理、代码修改等流程,我们将之前的 Travis-CI 迁移至速度更快、性能更好的 GitHub Action ,一方面可以优化我们的工作流,另一方面,也让我们的代码更加简洁明了。

对于还在使用 Travis CI 的项目来说,也可以考虑迁移到 GitHub Action 中,来优化自己的工作流。

参考阅读

  • https://mauricius.dev/run-and-debug-github-actions-locally/
  • https://jeffrafter.com/working-with-github-actions/
  • https://developer.okta.com/blog/2020/05/18/travis-ci-to-github-actions
black and white penguin toy

被 GitHub Action 坑了半天…

我这几天在忙着搞 LCTT 的 Travis-CI 迁移到 Github Action 。整体的 CI 的流程都已经迁移完成了,但是一个特定的检查脚本死活无法正常运行。

在这个过程中我尝试了多种办法,比如修改代码、调整里面的参数、打印其中的参数,似乎都是工作运行正常的。

将项目代码 clone 到本地后,发现代码在本地运转也是正常的。

我一直不知道问题出在哪里,百思不得其解。直到我在跑了几百次 Action 构建后,我发现,Github 默认的 checkout 插件是有问题的。

和标准的 git clone 不同, Github 默认的 Checkout 插件在实际 clone 项目是使用的不是 git clone 命令,而是采用先在本地 init 一个目录,并添加相应的 remote ,并 fetch 代码下来。

github action
GitHub Action 的 Clone

这样的好处是在处理的时候,只会 fetch 到特定的分支到本地,而不会将默认的其他分支一同 clone
到本地。但坏处就是你在执行的时候,只能针对特定的分支进行操作。

而检查脚本则是基于 git 本身的命令进行执行的,因此是需要比如 master 这样的分支的,这就导致在使用了默认的 checkout 插件的时候,检查脚本无法使用。

Travis-CI 的表现
Travis CI 的 Clone

与之对比的,是 Travis CI 在执行 Clone 的时候,采用的是全量 Clone ,再单独 Fetch 某个特定分支。从这个角度上来看,我可以理解 Github Action 为什么会 Clone 的更快一些。不过,这种 Clone 的方式确实给一些 CI 在 Check 时留下隐患。

总结

如果你在 Github 中使用默认的 Checkout 插件获取项目以后,执行 Git 操作出现了问题,很有可能是插件自己的问题,而不是你的问题。你可以选择自己构建 clone 命令,避免这个问题。

如何免费为你的组织项目配置 Vercel

前言

Vercel 是我自己非常喜欢的平台,我自己的一些项目都会选择使用 Vercel 来部署。比如 LogolyEasyWPBook 等等。

主要是其在中国大陆的访问速度是比 Netlify 和 Github Pages 更快。但不得不说的是,Vercel 提供了 Production 环境和 Development 环境,对于项目开发时是非常有用的,当你提交一个 commit 或者是一个 PR 时, Vercel 会自动帮你部署,并将相应的 URL comment 到你的 commit 或 PR 下,你只需要点击相应链接,就可以预览效果,十分方便。

但 Vercel 的 Teams 功能是付费的,对于一些 Organization 来说,你需要付费用 Vercel 成本是比较高的。特别是如果你是一个 OpenSource Project,你大概率入不敷出。在这种情况下,如何才能在 Organization Project 中免费使用 Vercel 呢?我考虑了一个绕过去的方法。

我们之所以无法使用在项目中无法免费使用 Vercel 是 Vercel 的产品策略问题。

而我们被禁用的无法使用官方自建的 Github Apps 来部署,但不意味着我们不可以自己实现这样的逻辑,来实现在组织内项目进行push。

而想要达成这样的效果,需要你具备两个条件

  1. 你的代码每一次提交都会自动触发 CI
  2. 你的 CI 中可以自动上传代码到 Vercel

而前者,可以通过 Github 提供的 Action 来完成。后者则可以通过编写代码来完成。不过好在,我在 Github 的 Marketplace 中找到了别人已经写好的 Action ,因此又可以少写一些代码(开心?)。

接下来,看看具体要如何操作。

步骤

安装依赖

在进行后续的操作之前, 你需要先安装配置过程中的依赖。

执行如下命令安装 Vercel CLI

npm i -g vercel

创建一个项目

为了正常部署,你需要创建一个项目,并将其 push 到 Github。当然,如果你已经创建好了项目,就直接把项目 Clone 到本地就好。

使用 Vercel 部署这个项目

这一步是为了在 Vercel 上创建一个项目,因为 Vercel 不支持通过网页端创建项目,只支持在 CLI 或通过 Git 接入自动创建。

在你的项目根目录,执行命令 vercel 来触发 Vercel 的部署,它会自动上传你的项目到 Vercel 。如果你之前登录过,会看到类似这样的界面,根据其提示进行配置就好。如果你之前没有登录过,你登录后会出现类似的界面。根据提示进行配置。

获取配置

想要部署一个项目到 Vercel ,你需要知道三样东西

  1. Access Token: 用于 CLI 的登录和 API 的调用,没有 Access Token ,Vercel 就没有办法获取到你的用户身份,进行鉴权校验。
  2. Org ID:Org ID 是指你在 Vercel 上的用户 ID。由于 Vercel 中一个人其实可以管理和配置多个 Team ,因此需要借助 Org ID 来指定要管理哪个账号下的项目。
  3. Project ID:很好理解,如果你要管理 Project ,就需要一个 Project ID。

其中,Access Token 你需要从 Vercel 后台的 Tokens 页面获取。

而 Org ID 则可以从你的项目中的 .vercel/project.json 中获取。你会获得类似下面这样的内容,其中的 OrgID 就是你在 Vercel 上的 ID ,而 Project ID 就是对应的项目 ID。

{"orgId":"r359XAnYONVAmiXtdxZ22A2E","projectId":"Qma3GdwoiAfJSsbsSydBgaCDh8LJj6wTWvvqpUwrN6J2F3"}

准备好了这三项以后,就可以进入到下一个环节,配置 Action Secret 了。

配置 Github Action Secret

Github Action 提供了 Secret 的机制,用来让你保存哪些安全密钥,避免直接写在 Action File 中,出现泄漏的可能。

打开你的项目的 Settings – Secrets 页面

在这里你可以新增 Secret ,你需要新增三个 Secret ,分别是

  • ORG_ID: 填写你从 .vercel/project.json 中获取到的 orgId;
  • PROJECT_ID:填写你从 .vercel/project.json 中获取到的 projectId;
  • VERCEL_TOKEN:填写你从 Vercel 后台生成的 Token。

这样,就配置好了 Secret ,接下来就可以在你的项目中加入 a、Action 配置文件,完成项目的配置。

添加 Action 配置文件

根据 Github 的规范,你需要将你的 Action 配置文件放置在项目根目录的 .github/workflows/xxx.yml 文件中,其中 xxx 是你的 Action 名,比如叫 vercel.yml

这里我使用的是 ngduc 写的 vercel-deploy-action

按照路径创建好 vercel.yml 文件,然后在其中加入如下代码

name: deploy website
on:
  push:
    branches:
      - master
  pull_request:
    branches:
      - master
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: ngduc/vercel-deploy-action@master
        with:
          vercel-cli: vercel
          vercel-token: ${{ secrets.VERCEL_TOKEN }}
          vercel-org-id: ${{ secrets.ORG_ID}}
          vercel-project-id: ${{ secrets.PROJECT_ID}}
          github-token: ${{ secrets.GITHUB_TOKEN }}

粘贴进去以后,将 vercel.yml 添加到 git 控制中,并提交到 Github 上,就可以实现触发 Vercel 了。

总结

虽然 Vercel 本身不能免费提供 Organization 的支持,但是我们可以通过一些小的技巧,绕过其官方的配置。对于一些只是将 Vercel 配置为开发者预览的场景下来说,还是足够的。

但如果你希望将 Vercel 配置为生产环境,那么 Teams Plan 可以提供的更多的权限控制,会是你需要的,买一个,也不贵,是吧?