CI/CD on Time Friend

我是怎么部署这个博客的

Thu, 10 Apr 2025 15:44:00 +0000

静态文件总得找个地方放, 还得让全世界都能访问.

部署平台: Cloudflare Pages

选 Cloudflare Pages 而不是其他平台, 原因有三:

全球 CDN: Cloudflare 有遍布全球的边缘节点, 无论访客在哪, 都能从最近的节点加载页面
零配置 HTTPS: 自动签发和续期 SSL 证书, 不需要手动处理
免费额度够用: 对于个人博客来说, 带宽和构建次数完全够用

配置很简单, 在 Cloudflare Pages 控制台创建一个项目, 关联 GitHub 仓库. 构建命令和输出目录在 GitHub Actions 里控制, 不需要在控制台配.

有个坑: Cloudflare Pages 默认分配的域名是 <project>.pages.dev, 项目名一旦确定就不能改. 想换只能删掉重建. 我那会儿随便打了个名字, 后来想改发现不行, 只能留着.

CI/CD 流程

完整的部署流程由 GitHub Actions 管理:

name: Deploy to Cloudflare Pages

on:
 push:
 branches: [master]
 workflow_dispatch:

jobs:
 build:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4

 - uses: peaceiris/actions-hugo@v3
 with:
 hugo-version: "0.164.0"
 extended: true

 - uses: actions/setup-node@v4
 with:
 node-version: 24
 cache: npm

 - name: Install dependencies
 run: npm ci

 - name: Patch theme for Hugo compatibility
 run: bash scripts/patch-theme.sh

 - name: Build
 run: npm run build

 - name: Deploy to Cloudflare Pages
 run: npx wrangler pages deploy public --project-name=time-friend
 env:
 CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
 CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}

触发条件是 push 到 master 分支. 也支持手动触发 (workflow_dispatch), 方便在不改代码的情况下重新部署.

博客的构建流水线是怎么跑的

Wed, 05 Mar 2025 16:30:00 +0000

文章写完之后, 总不能手动一条条部署. 自动化的目的很简单: push 完代码就什么都不用管了.

本质上就两件事: 把 Markdown 变成静态文件扔到网上去, 顺便把构建流程自动化.

Gulp 任务

整个构建就两个 Gulp 任务, 串行跑:

gulp.task("default", gulp.series('build', 'generate-service-worker'));

build

gulp.task('build', () => gulp.src('./').pipe(shell(['hugo --buildFuture --minify'])));

一行代码. 调用 Hugo 构建, --buildFuture 允许发布未来日期的内容, --minify 在构建时做 HTML/CSS/JS 压缩.

为什么用 gulp-shell 而不是直接调用 Hugo? 因为后续需要在构建完成后做一些处理, Gulp 作为编排工具把任务串起来比较方便. 如果用 npm script 串命令也可以, 但 Gulp 的 task 定义更清晰, 错误处理也更直接.

generate-service-worker

gulp.task('generate-service-worker', () => {
 return workbox.generateSW({
 globDirectory: './public',
 globPatterns: ['**/*.{woff2,woff,js,css,png.jpg}'],
 globIgnores: ['sw.js'],
 swDest: `./public/sw.js`,
 clientsClaim: true,
 skipWaiting: true,
 runtimeCaching: [
 { urlPattern: /.*\.js/, handler: 'NetworkFirst' },
 { urlPattern: /.*\.css/, handler: 'StaleWhileRevalidate' },
 { urlPattern: /.*\.(?:png|jpg|jpeg|svg|gif)/,
 handler: 'CacheFirst',
 options: { cacheName: 'images', expiration: { maxEntries: 50 } } },
 { urlPattern: /.*\.html/, handler: 'NetworkFirst' }
 ]
 })
 .then(() => console.info('Service Worker 生成完成'))
 .catch(error => console.warn('Service Worker 生成失败: ' + error));
});

这个任务用 Workbox 自动生成 SW, 具体原理和缓存策略在 PWA 与 Service Worker 那篇里讲了.

持续集成 - 代码质量扫描

Sun, 15 Dec 2019 23:15:00 +0000

为了方便管理公司的代码质量,让代码质量扫描跟持续集成结合到一起是重要的一步. 目前公司比较年轻,但是在短短的一年时间里,也有了接近300个前端项目.

这么多的前端项目,我们如何保证代码质量就成了一个很重要的事情.

代码项目太多,codereview是必要的.但是人肉codereview不能保证效率. 因为个人水平的差距,与公司规范的熟悉程度.不能保证所有项目的规范一致性. 还有一些潜在的bug也有可能会被漏掉.

我们公司是基于Gitlab CI/CD,所以以下说明是基于Gitlab的方式.但是思路的运用是相通的,有需要的人可以借鉴思路.

修改.gitlab-ci.yml

为了方便每一个项目接入,我们对配置做了很小的改动. 并且每一个项目的配置的修改都是一样的,就是为了方便无脑的复制粘贴.

我们还做了一个cli工具,里面包含代码扫描的一切功能.安装在runner的机器上.

image: node:11.10.0

stages:
 - codereview # 添加一个codereview的stage

codereview:
 stage: codereview
 script:
 - cli codereview # cli工具触发codereview
 tags:
 - fe #runner的tag,根据自己的情况自行修改

cli 触发代码扫描做什么?

执行SonarQube扫描

关于SonarQube的安装,网上有很多教程请自行搜索.

在执行runner的机器上安装 sonar-scanner

npm i sonar-scanner -g

利用自研的cli工具,在项目根目录生成sonar 扫描的配置文件.


// 获取gitlab 注入ci的环境变量
const {
 CI_PROJECT_NAME,
 CI_PROJECT_ID,
} = process.env;

// 基于gitlab的项目id生成一个sonar的projectKey
const projectBuffer = Buffer.from('sonar' + CI_PROJECT_ID);
const projectKey = projectBuffer.toString('hex');

// 检测代码目录
// 一般来说 src都是前端项目业务代码的目录
//因为公司的nodejs项目是基于egg框架的,也有可能是app
const existsSrc = fs.existsSync(`${process.cwd()}/src/`);



// sonar配置文件模板
const sonarProject = `
sonar.projectKey=${projectKey} 

sonar.projectName=${CI_PROJECT_NAME}

sonar.projectVersion=1.0

sonar.sources=${existsSrc ? 'src' : 'app'}

sonar.binaries=bin

sonar.host.url=http://xxx.你部署sonar的服务地址.com 

sonar.login=admin

sonar.password=admin

sonar.sourceEncoding=UTF-8
`;
 // 生成一个路径
 const sPath = path.resolve(process.cwd(), 'sonar-project.properties');

 // 写入sonar的配置
 fs.writeFileSync(sPath, sonarProject);

 // 执行sonar的代码扫描,并且上传代码质量报告
 shelljs.exec('sonar-scanner');

执行jscpd分析代码重复率

尽管sonar已经提供了代码重复率的报告,但是并不是很容易看懂,到底代码哪里重复. 我们使用jscpd来分析项目的重复率.并且输出友好的报告.

持续集成 - 使用Gilab CI进行前端项目的持续集成

Fri, 20 Sep 2019 23:15:00 +0000

市面上的持续集成平台有很多,今天介绍Gitlab的CI.

从Gitlab 8.0开始,Gitlab CI 就集成在了Gitlab中.

使用方法非常简单,只要我们在项目的根目录创建一个 .gitlab-ci.yml文件,添加一个Runner,就直接接入了Gitlab CI.

接入方式非常的简单便捷.目前我们在前端脚手架中放一个.gitlab-ci.yml文件,后续每一个前端项目都可以按照标准直接接入Gitlab CI.

GitLab Runner

所有的Gitlab任务都会放在Gitlab Runner中执行.

GitLab Runner的安装环境,根据你的需求而定,一个gitlab 可以注册的Runner是没有限制的.

普通的前端项目直接安装在Linux中就可以了,如果是小程序或者RN这种项目,目前我是直接找了一台mac mini来安装Runner.

GitLab Runner安装

安装Runner 非常简单, 这里晒出Gitlab的官方安装教程,你可以根据你的系统环境自行下载.

安装Gitlab Runner 官方文档

注册Runner

Runner安装好之后,想要关联到你的Gitlab,需要注册Runner.

这里给大家介绍群组的runner注册方式,个人项目的runner方式注册基本一致

注册Gitlab Runner 官方文档

大致流程为:

打开Gitlab网站,选择群组-> 设置-> CI/CD -> 展开Runner -> 你会看到注册Runner的Token与Url
安装好Runner的机器上,运行 sudo gitlab-runner register
输入你Gitlab的 URL
输入 Token
输入 Runner 的名字
选择 Runner 的类型,没有特殊需求直接选shell
完成

配置Runner

Runner的配置文件会以执行的用户身份不同而不同

当GitLab Runner以root身份执行时 /etc/gitlab-runner/config.toml
当GitLab Runner以非root身份执行时 ~/.gitlab-runner/config.toml

Runner的全局配置

这里我只说关键的两点

concurrent 配置会限制整个GitLab Runner能并发处理job的数量,如果你发现你的runner当前时间全局只能执行一个job的时候, 可以检查concurrent是否默认配置为1.不然多个job同一时段并发的时候,会造成job排队的现象.

使用Travis CI自动化部署你的Hugo,Hexo博客

Tue, 20 Nov 2018 16:14:25 +0000

Travis CI 是什么?

Travis CI 是在线托管的 CI 服务，用 Travis 来进行持续集成，不需要自己搭服务器。最重要的是，它对开源项目是免费的。如果公司是用的是 gitlab,也有提供相应的持续集成服务.这里就过多赘述.

Travis CI 配置文件

Travis 要求项目的根目录下面，必须有一个.travis.yml文件。

当你的仓库有提交的时候,travis 会自动执行你下面配置的行为.

Travis CI 的钩子与生命周期

Travis 的钩子

Travis 有不同的阶段,他提供了 7 个钩子。

before_install：install 阶段之前执行
before_script：script 阶段之前执行
after_failure：script 阶段失败时执行
after_success：script 阶段成功时执行
before_deploy：deploy 步骤之前执行
after_deploy：deploy 步骤之后执行
after_script：script 阶段之后执行

生命周期

before_install
install
before_script
script
aftersuccess or afterfailure
[OPTIONAL] before_deploy
[OPTIONAL] deploy
[OPTIONAL] after_deploy
after_script

.travis.yml

下面是我的博客部署配置,也是我项目.travis.yml文件的内容.

hugo

这是我的 hugo 部署配置,仅供参考

language: node_js
node_js: 10.13.0
install:
 - wget https://github.com/gohugoio/hugo/releases/download/v0.51/hugo_0.51_Linux-64bit.deb
 - sudo dpkg -i hugo*.deb
 - hugo version
 - rm -rf public
 - npm install

script:
 - hugo --buildFuture
 - gulp
 - echo 'Build done!'
after_success:
 - git config --global user.name "Fan"
 - git config --global user.email "你的邮箱"
 - git clone https://${ACCESS_TOKEN}@github.com/Num142857/alili.tech.git container
 - rm -rf container/*
 - cp -r public/* container
 - cd container
 - git add .
 - git commit -m 'Travis upate blog'
 - git push -u origin gh-pages -f

Hexo

这是我的 hexo 部署配置,仅供参考.

自动化部署前端代码 - grunt-ftp-deploy的使用

Sun, 14 Jun 2015 23:36:00 +0000

每一次修改完代码之后,要部署到远程的服务器,我的操作步骤是:

修改代码 –> grunt build –> 打开FileZilla –>登录ftp服务器 –>找到本地文件夹 –> 找到远程服务器目标文件夹 –>全选本地文件 –> 上传

因为部署代码,在某个时候会特别频繁.每一次都要重复上面的八个操作.表示要做点什么,改变一下.

今天我们的主角:grunt-ftp-deploy

如果是sftp可以使用grunt-sftp-deploy

安装:

npm install grunt-ftp-deploy --save-dev

or

npm install grunt-sftp-deploy --save-dev

在与Gruntfile文件同一目录,我们新建一个".ftppass"的文件, 里面是ftp的授权信息, 内容如下:

{
 "key1": {
 "username": "username",
 "password": "password"
 }
}

Gruntfile配置代码:

//ftp-deploy
 grunt.initConfig({
 'ftp-deploy': {
 build: {
 auth: {
 host: '192.168.1.245', //ftp服务器的ip地址
 port: 21,//服务器端口
 authKey: 'key1'//.ftppass文件里,key1的授权信息
 },
 src: 'path/to/source/folder',//本地文件夹
 dest: '/path/to/destination/folder',//服务器的目标文件夹
 exclusions: ['path/to/source/folder/**/.DS_Store']//不上传的文件
 }
 }
 })

//sftp-deploy
 grunt.initConfig({
 'sftp-deploy': {
 build: {
 auth: {
 host: '192.168.1.245', //ftp服务器的ip地址
 port: 21,//服务器端口
 authKey: 'key1'//.ftppass文件里,key1的授权信息
 },
 cache: 'false',
 src: 'path/to/source/folder', //本地文件夹
 dest: '/path/to/destination/folder', //服务器的目标文件夹
 serverSep: '/',//服务器的相对路径
 localSep: '/',//本地的相对路径
 concurrency: 20,//每次上传多少个文件
 progress: true //是否显示进度条
 }
 }
 })

加载task

烦人的AngularJS注解 - grunt-ng-annotate的使用

Fri, 12 Jun 2015 23:15:00 +0000

angular加入了依赖注入

编写代码的时候,大致的写法如下

 app.controller('tempController', function($scope, $http, $state, $timeout) {

 ...

 })

可是这样的代码,压缩后会造成一个问题. 函数的参数:$scope, $http, $state, $timeout会变成: a,b,c,d

导致这个函数找不到需要注入的服务,因为每个参数的命名都是严格规定的.

如下:

 app.controller('tempController', function(a,b,c,d) {

 ...

 })

为了解决这个问题,angular支持如下写法:

 app.controller('tempController', ["$scope", "$http", "$state", "$timeout", function($scope, $http, $state, $timeout) {



 }])

那么问题来了:

每一次添加一个服务的时候,都需要写两遍. 每一次删除一个服务的时候,都需要删两遍.

表示大大降低了变成的愉悦.

那么我们怎么解决这个问题呢?

今天的主角来了,那就是grunt-ng-annotate

这是一个grunt的插件,当然在glup上也有.因为我的项目主要是用grunt写的. 那么这次主要讲grunt版本的ng-annotate.

首先我们需要安装ng-annotate:

npm install grunt-ng-annotate --save-dev

在你的Gruntfile里运行这个插件:

grunt.loadNpmTasks('grunt-ng-annotate');

配置代码:

grunt.initConfig({
 ngAnnotate: {
 dist: {
 files: [{
 expand: true,
 cwd: '<%= yeoman.dist %>', //相对路径
 src: '**/*Controller.js', //需要匹配的文件
 dest: '<%= yeoman.dist %>' //文件输出的路径
 }]
 }
 }
})

js代码在函数里加入 “ngInject”: