年后刚开工还没有活的时候无聊翻了一下自己Github，发现之前的项目预览挂了，便乘机修复。之前都是直接使用Github Pages的默认域名进行项目展示，感觉有点不爽，虽然我的个人博客现在木了，但是域名还在呀，为什么不能用自己的个人域名来展示项目呢？
于是一番折腾，最终实现了在只依赖Github Pages时，使用同一个自定义域名来展示多个Github项目。
效果如下：
helianthuswhite.cn/vue-weather
在实现过程中，主要包含了以下两个关键步骤：
- 通过
iframe进行项目路由 - 通过
github actions实现项目自动部署
通过iframe进行项目路由
主仓库配置自定义域名
Github 提供了使用自定义域名展示 Github Pages 的方式，如下图所示，具体的配置方式官方已经给了详细的文档，可以查看Github Pages配置自定义域名。
但是官方提供的方式并不支持将一个自定义域名同时绑定到多个项目，这里我们考虑通过 iframe 转发的方式将自定义域名的路径转换为 helianthuswhite.github.io/xxxx。
由于在主仓库中我们并没有处理路由逻辑，当访问 helianthuswhite.cn/xxxx 时 Github Pages 找不到对应的页面，便会返回404。默认 Github 会先去找当前仓库下是否存在404.html文件，若存在则返回改文件页面，否则使用 Github 默认的404页面。
基于上述情况，我们可以在主仓库中创建404.html文件并通过下面的代码实现页面请求的转发：
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Helianthuswhite</title>
<link rel="stylesheet" href="/index.css" />
</head>
<body>
<script>
var baseUrl = 'https://helianthuswhite.github.io';
var project = window.location.pathname;
var iframe = document.createElement("iframe");
iframe.width = '100%';
iframe.height = '100%';
iframe.frameborder = 0;
iframe.src = baseUrl + project;
document.body.appendChild(iframe);
</script>
</body>
</html>
这里也不用担心会影响原有的404逻辑，当请求转发到 helianthuswhite.github.io 域名下时，原有的404依然会返回。
完整的主仓库代码可以参考：github.com/helianthusw… ，填加了样式文件以消除浏览器默认样式对iframe的影响。
项目仓库配置Pages
若项目仓库未配置过 Github Pages，则可以通过官方文档中的方式进行配置——配置Github Pages。配置完成后可以通过 helianthuswhite.github.io/xxxx 的方式访问项目页面，如下图所示：
完成上述配置后，那我们已经可以通过「自定义域名/项目名称」的方式访问到该项目啦~ 🎉🎉🎉
对多个不同的项目都配置Pages，便可以实现同一个域名访问不同的项目。
通过Github Actions实现项目自动部署
该部分为本文的衍生产物，与本文的核心无关，不感兴趣的看官可以直接跳过。
该章节以 github.com/helianthusw… 项目为例。
进入项目仓库，选择顶部Actions栏目，点击set up a workflow yourself进入到自定义工作流的配置页面。
进入配置页面后，Github 会自动在项目根目录创建 .github/workflows/xxxxx 的工作流配置文件，文件名称可自由指定。同时 Github 也提供了在线的配置文件编辑功能，左侧为编辑和预览区，在右侧的 Marketplace 中可以看到各种各样官方或其他开发者提供的工作流配置。
后面的工作主要就是书写该项目的工作流配置文件，即 build.yml，具体的语法这里不多介绍，可以查看官方提供的文档Github Actions语法说明。
对于项目 Pages 部署的工作流，这里使用开源项目 github.com/JamesIves/g… 来实现，完整的配置文件如下所示：
# 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 "master" branch
push:
branches: [ "master" ]
pull_request:
branches: [ "master" ]
# 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:
# This workflow contains a single job called "build"
build:
# The type of runner that the job will run on
runs-on: ubuntu-latest
permissions:
contents: write
# Steps represent a sequence of tasks that will be executed as part of the job
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- name: Checkout a new branch
uses: actions/checkout@v3
# Runs a set of commands using the runners shell
- name: Run install and build
run: |
npm i
npm run build
- name: Deploy to gh-pages
uses: JamesIves/github-pages-deploy-action@v4.4.1
with:
folder: dist
该工作流指定了当 master 分支发生 push 或者 pull request 事件时触发，一共包含三个步骤：
checkout一个新的分支- 通过
npm i和npm run build命令执行构建 - 指定将构建后的
dist目录文件更新到gh-pages分支
配置文件书写完成并提交到仓库的 master 分支后，点击 Actions 栏目，可以看到正在执行的工作流情况。
点击某一条工作流，选择工作流中的某个 Job，点击进入该 Job 的详情页，可以在详情页中看到具体的执行内容以及每条执行命令的日志。当有命令执行失败时，便可以在这里查看详细的失败原因。
当上述工作流执行完成之后，我们可以看到项目仓库的 gh-pages 分支已经自动更新，此时再刷新页面 helianthuswhite.cn/vue-weather… 便可以看到页面也已经更新。
后续我们只需要正常进行项目开发并提交代码，再也不用手动构建更新项目页面~
