Bump url-parse from 1.5.1 to 1.5.7

.github/workflows/nodejs.yml

@@ -1,46 +1,46 @@
-name: deploy to aliyun oss
+# name: deploy to aliyun oss
 
 # on:
 #   push:
 #   schedule:
 #   - cron:  '30 20 * * *'
 
-jobs:
-  build:
+# jobs:
+#   build:
 
-    runs-on: ubuntu-latest
+#     runs-on: ubuntu-latest
 
-    steps:
-    - uses: actions/checkout@v1
-    - uses: bahmutov/npm-install@v1
-    - run: ls -lah
-    # 下载 git submodule
-    - uses: srt32/git-actions@v0.0.3
-      with:
-        args: git submodule update --init --recursive
-    # 使用 node:10
-    - name: use Node.js 14.x
-      uses: actions/setup-node@v1
-      with:
-        node-version: 14
-    - run: |
-        node -v
-    # npm install
-    - name: npm install
-      run: npm install
-    - name: build
-      run: npm run build
-    # 设置阿里云OSS的 id/secret，存储到 github 的 secrets 中
-    - name: setup aliyun oss
-      uses: manyuanrong/setup-ossutil@master
-      with:
-        endpoint: oss-cn-beijing.aliyuncs.com
-        access-key-id: ${{ secrets.OSS_KEY_ID }}
-        access-key-secret: ${{ secrets.OSS_KEY_SECRET }}
-    - name: 删除冗余文件
-      run: ossutil rm oss://shanyue-blog/assets -rf
-      if: github.event_name == 'schedule'
-    - name: 复制文件到阿里云OSS
-      run: ossutil cp -rf .vuepress/dist oss://shanyue-blog/
-    - name: 设置永久缓存
-      run: ossutil set-meta oss://shanyue-blog/assets cache-control:"max-age=31536000" --update -rf
+#     steps:
+#     - uses: actions/checkout@v1
+#     - uses: bahmutov/npm-install@v1
+#     - run: ls -lah
+#     # 下载 git submodule
+#     - uses: srt32/git-actions@v0.0.3
+#       with:
+#         args: git submodule update --init --recursive
+#     # 使用 node:10
+#     - name: use Node.js 14.x
+#       uses: actions/setup-node@v1
+#       with:
+#         node-version: 14
+#     - run: |
+#         node -v
+#     # npm install
+#     - name: npm install
+#       run: npm install
+#     - name: build
+#       run: npm run build
+#     # 设置阿里云OSS的 id/secret，存储到 github 的 secrets 中
+#     - name: setup aliyun oss
+#       uses: manyuanrong/setup-ossutil@master
+#       with:
+#         endpoint: oss-cn-beijing.aliyuncs.com
+#         access-key-id: ${{ secrets.OSS_KEY_ID }}
+#         access-key-secret: ${{ secrets.OSS_KEY_SECRET }}
+#     - name: 删除冗余文件
+#       run: ossutil rm oss://shanyue-blog/assets -rf
+#       if: github.event_name == 'schedule'
+#     - name: 复制文件到阿里云OSS
+#       run: ossutil cp -rf .vuepress/dist oss://shanyue-blog/
+#     - name: 设置永久缓存
+#       run: ossutil set-meta oss://shanyue-blog/assets cache-control:"max-age=31536000" --update -rf

frontend-engineering/deploy/ci-ci.md

@@ -49,6 +49,27 @@ on:
       - 'feature/**'
 ```
 
+## 分支的合并策略与 CI (主分支保护规则)
+
+**生产环境的代码必须通过 CI 检测才能上线**，但这也需要我们进行手动设置。
+
+一般而言，我们会设置以下策略加强代码的质量管理。
+
+1. 主分支禁止直接 PUSH 代码
+1. 代码都必须通过 PR 才能合并到主分支
+1. **分支必须 CI 成功才能合并到主分支**
+1. 代码必须经过 Code Review (关于该 PR 下的所有 Review 必须解决)
+1. 代码必须两个人同意才能合并到主分支
+
+在 Gitlab 与 Github 中均可进行设置:
+
++ [Github: Managing a branch protection rule](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule)
++ [Gitlab: Merge when pipeline succeeds](https://docs.gitlab.com/ee/user/project/merge_requests/merge_when_pipeline_succeeds.html)
+
+如下示例，未通过 CI，不允许 Merge。可见示例 [PR #22](https://github.com/shfshanyue/cra-deploy/pull/22)。
+
+![](https://cdn.jsdelivr.net/gh/shfshanyue/assets/2022-02-11/clipboard-2703.b42555.webp)
+
 ## 任务的并行与串行
 
 在 CI 中，互不干扰的任务并行执行，可以节省很大时间。如 Lint 和 Test 无任何交集，就可以并行执行。
@@ -238,7 +259,9 @@ Lint 和 Test 仅是 CI 中最常见的阶段。为了保障我们的前端代
 
 有些细心并知识面广泛的同学可能注意到了，某些 CI 工作也可在 Git Hooks 完成，确实如此。
 
-它们的最大的区别在于一个是客户端检查，一个是服务端检查。而客户端检查是天生不可信任的。而针对 `git hooks` 而言，很容易通过 `git commit --no-verify` 而跳过。
+它们的最大的区别在于一个是客户端检查，一个是服务端检查。而客户端检查是天生不可信任的。
+
+而针对 `git hooks` 而言，很容易通过 `git commit --no-verify` 而跳过。
 
 ![](https://cdn.jsdelivr.net/gh/shfshanyue/assets@master/src/image.png)
 

frontend-engineering/deploy/ci-env.md

@@ -1,8 +1,12 @@
 # CI 中的环境变量
 
+在以前诸多章节中都会使用到环境变量。比如在 OSS 篇使用环境变量存储云服务的权限。在前端的异常监控服务中还会用到 Git 的 Commit/Tag 作为 Release 方便定位代码，其中 Commit/Tag 的名称即可从环境变量中获取。
+
+而在后续章节还会使用分支名称作为功能测试分支的前缀。
+
 ## 环境变量
 
-在 Linux 系统中，通过 `env` 可列出所有环境变量，我们可对环境变量进行修改与获取操作。
+在 Linux 系统中，通过 `env` 可列出所有环境变量，我们可对环境变量进行修改与获取操作，如 `export` 设置环境变量，`${}` 操作符获取环境变量。
 
 ``` bash
 $ env
@@ -11,10 +15,16 @@ USER=shanyue
 $ echo $USER
 shanyue
 
+# 或者通过 printenv 获取环境变量
+$ printenv USER
+
 $ export USER=shanyue2
 
 $ echo $USER
 shanyue2
+
+# 获取环境变量 Name 默认值为 shanyue
+$ echo ${NAME:-shanyue}
 ```
 
 我们在前后端，都会用到大量的环境变量。环境变量可将非应用层内数据安全地注入到应用当中。在 node.js 中可通过以下表达式进行获取。
@@ -27,7 +37,7 @@ process.env.USER
 
 CI 作为与 Git 集成的工具，其中注入了诸多与 Git 相关的环境变量。以下列举一条常用的环境变量
 
-如 Github Actions 中
+如 [Github Actions virables](https://docs.github.com/en/actions/learn-github-actions/environment-variables#default-environment-variables) 中
 
 | 环境变量 | 描述 |
 | --- | --- |
@@ -37,8 +47,7 @@ CI 作为与 Git 集成的工具，其中注入了诸多与 Git 相关的环境
 | `GITHUB_SHA` | 当前的 Commit Id。 `ffac537e6cbbf934b08745a378932722df287a53`. |
 | `GITHUB_REF_NAME` | 当前的分支名称。|
 
-如 [Gitlab CI envirables](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html) 中
-
+如 [Gitlab CI virables](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html) 中
 
 | 环境变量 | 描述 |
 | --- | --- |
@@ -86,7 +95,11 @@ $ CI=true npm run build
 
 ![](https://cdn.jsdelivr.net/gh/shfshanyue/assets/2022-01-11/clipboard-9125.9b3a8e.webp)
 
-+ [Github CI Run](https://github.com/shfshanyue/cra-deploy/runs/4771781199?check_suite_focus=true)
+> PS: 本次 Action 执行结果 [Github Actions Run](https://github.com/shfshanyue/cra-deploy/runs/4771781199?check_suite_focus=true)
+
+为了验证此类环境变量，我们可以通过 CI 进行验证。
+
+另外，在 Github Actions 中还可以使用 `Context` 获取诸多上下文信息，可通过 `${{ toJSON(github) }}` 进行获取。
 
 ``` yaml
 name: CI Env Check
@@ -101,4 +114,24 @@ jobs:
       - run: echo $GITHUB_EVENT_NAME
       - run: echo $GITHUB_SHA
       - run: echo $GITHUB_REF_NAME
-```
+      - run: echo $GITHUB_HEAD_REF
+      - name: Dump GitHub context
+        run: echo '${{ toJSON(github) }}'
+```
+
+## 一个项目的环境变量管理
+
+一个项目中的环境变量，可通过以下方式进行设置
+
+1. 本地/宿主机拥有环境变量
+1. CI 拥有环境环境变量，当然 CI Runner 可认为是宿主机，CI 也可传递环境变量 (命令式或者通过 Github/Gitlab 手动操作)
+1. Dockerfile 可传递环境变量
+1. docker-compose 可传递环境变量
+1. kubernetes 可传递环境变量 (env、ConfigMap、secret)
+1. 一些配置服务，如 [consul](https://github.com/hashicorp/consul)、[vault](https://github.com/hashicorp/vault)
+
+而对于一些前端项目而言，可如此进行配置
+
+1. 敏感数据放在 [vault] 或者 k8s 的 [secket] 中注入环境变量
+1. Git/OS 相关通过 CI 注入环境变量
+1. 非敏感数据可放置在 `.env` 中

frontend-engineering/deploy/ci-intro.md

@@ -83,7 +83,7 @@ github 提供了以下配置的服务器作为构建服务器，可以说相当
 on: push
 ```
 
-更多 Github Actions 事件可以参考官方文档 [Events that trigger workflows](https://help.github.com/en/actions/automating-your-workflow-with-github-actions/events-that-trigger-workflows#about-workflow-events)
+更多 Github Actions Event 可以参考官方文档 [Events that trigger workflows](https://help.github.com/en/actions/automating-your-workflow-with-github-actions/events-that-trigger-workflows#about-workflow-events)
 
 ``` yaml
 # 仅仅当 master 代码发生变更时，用以自动化部署
@@ -193,11 +193,14 @@ deploy:
     - master
   script:
     # 构建镜像
-    - docker build -t devtools-app-image
+    - docker build -t cra-deploy-app .
     # 推送镜像
-    - docker push devtools-app-image
-    # 拉取并部署，devtools-app-servie 将会拉取远程的 devtools-app-image 镜像，进行服务部署
-    - deploy devtools-app-service .
+    - docker push cra-deploy-app
+    # 拉取镜像并部署，deploy 为一个伪代码命令，在实际项目中可使用 helm、kubectl
+    - deploy cra-deploy-app .
+
+    # - kubectl apply -f app.yaml
+    # - helm install cra-app cra-app-chart
 ```
 
 ## 小结