搞了下Github Profile

前言

上段时间 Github 支持了自定义个人 Profile 页面，如果有一个用户名同名的仓库且包含README.md就会读取其内容显示在 Profile 页面头部。趁着周末我也搞了下自己的 Profile 页面，看看效果:

接着分享一下内容是怎么来的，以及如何自定义 Actions

内容

README.md 本质上还是用 markdown 语法，但是为了更好实现一些样式和结构可以直接写 HTML，但是自定义的限制还是比较多的，例如写的 CSS 不生效，即便用 style 标签写进去也不可以。

这个 README.md 包含 7 个部分:

个人介绍。markdown 语法配合 a 标签 (主要为了能加 target="_blank"，这样点击链接是在一个新页面打开)
语言和工具介绍。这部分是一排 icon，使用 img 标签，链接都是 devicons 项目下的地址
联系我的链接列表。也是一排 icon，不过由于没找到统一设计的社交 icon，最后只能从多个网站上找了一些喜欢的 icon，为了防止第三方网站挂掉，直接把 icon 放在项目里引用
访问者计数。使用了 visitor-badge.laobi.icu
博客文章列表。使用了 blog-post-workflow 定期抓取我最近发布的博客文章列表
我的豆瓣动态。这是一个我用 Go 写的 Actions，定期抓取我最近的豆瓣动态
Github 统计。使用了 github-readme-stats 获取动态生成的 GitHub 统计信息，我这里只显示「最常用语言」这个卡片。

按照惯例，在一开始我就用Awesome XX关键词搜索过，找到了 2 个对应的汇总 Github 用户 Profile 效果的项目:

上面的blog-post-workflow和github-readme-stats就是这么找到的，这个过程里面见识了很多开发者有趣的 Profile 效果✨

自定义 Action

GitHub Actions 是 GitHub 在 2018 年底推出的持续集成服务，官方说的是

GitHub Actions enables you to create custom software development life cycle (SDLC) workflows directly in your GitHub repository.

可以把软件开发中的安装部署、初始化、测试、发布等等工作流程作为单个 Action (操作)，不同项目的这种 Actions 其实是互通的，可以共享，Github 允许开发者把每个 Actons 写成独立的脚本文件，存放到代码仓库，当别人需要这种操作时就可以直接引用了。

在这里有必要再说 Workflow (工作流)，一会也会用到。官方说:

A workflow is a configurable automated process made up of one or more jobs. You must create a YAML file to define your workflow configuration.

就是可以用 YAML 文件配置这些任务的自动化流程，在 Python 世界里可以类比自动化工具里的Ansible Playbook。Action 和 Workflow 的关系是:

Workflow 是项目自动化的起点。需要把配置文件放在仓库的 .github/workflows 目录下，按照配置的周期运行。
在一个 Workflow 可以有多个 Action，按照一定顺序执行

工作流配置文件的语法在延伸阅读链接 4。

GitHub 有官方市场，可以搜索到他人提交的 actions。我编写的这个 actions 也可以被找到（可以搜索 douban，也可以在项目地址后侧找到入口），链接在延伸阅读有。

回过头，思考一下 Profile 页面为什么需要 Actions 呢？就拿我的来说，README 本质上是静态的内容，但是其中的博客文章列表、豆瓣动态、最常用语言统计是动态生成的，也就是说需要有程序在某个 (些) 时间获取内容再将其写入 README 中。

「我的豆瓣动态」的项目地址，新建项目是用了 go-action 这个模板，后来发现原来不是官方... 后来又搜了一下其实也没其他的选择，对于不熟悉 actions 的新手，新建一个使用 Golang 的 actions 来说我觉得挺好的。看一下项目目录结构:

❯ tree
.
├── LICENSE
├── README.md
├── action.yml
├── dist
│   ├── index.js
│   ├── main_darwin
│   ├── main_linux
│   └── main_windows.exe
├── go-action
├── go.mod
├── go.sum
└── main.go

1 directory, 11 files

主程序 main.go，代码逻辑简单，总体上是 2 部分:

使用 colly 抓取我的豆瓣动态列表，获得每个广播链接并按照不同的类型生成标题
写入 README.md

项目需要先安装依赖 colly，所以使用 Go Modules 来管理。

action.yml是 Action 的配置文件，使用 YAML 语言设置名字、作者、描述、标志、输入参数等项，全部配置选项可以看延伸阅读链接 3。需要说一下，看起来现在只支持 Node.js 和 Docker 这 2 种执行代码的方式，如我这里:

runs:
  using: 'node12'
  main: 'dist/index.js'

这是一个使用 Golang 的 action，所以需要在 index.js 里运行 Go 程序，这就是go-action这个模板项目的价值，它让 Golang 开发者不需要关注这部分细节。说到这就提到 dist 目录下三个main_开头的可执行文件，他们是不同平台生成的，在.github/workflows/build-dist.yml里有构建三种平台文件的用法。

这里等一下，再回忆一下 workflow 和 action:

douban-activity-readme 项目是一个 action，但是 dist/index.js 需要执行的二进制文件通过项目里的工作流 (workflow) 生成
douban-activity-readme 项目也有自己的 workflow，里面会生成需要的可执行文件

Action 踩坑

可以在配置文件中决定那些分支的代码提交会触发 workflows，例如这个项目
如果这种需要构建各平台的文件的这种需要等待自动化完成的用法，提交代码后需要等到 workflows 都完成测试没问题了再 release。
在 Github 网页版里有单独的 Actions Tab，可以在里面看到执行时间执行过程等信息，非常像 Travis-ci，如果发现好像构建不对，可以看日志报错

后记

说了半天，上代码，我的 README.md