2020年9月新版Coding静态网站由腾讯云静态网站提供服务,因此是收费的,可参见《Coding Pages 与腾讯云静态网站合并后变相为收费》
看官网文档是支持
Jekyll,Hexo,Gatsby,Zola
预编译功能的,因此如果你现在用的是新版,不妨看看官网文档的方案,而不是下面方案,虽然下面方案也适用Coding新版。
流程介绍
前面写了一篇文章《Github Actions自动部署Hexo博客》,是可以通过Github本身自带的持续集成功能来处理hexo项目,从而免去了在本地执行这项操作,只需要在Github上编写Markdown文档即可实现自动部署到hexo博客。
这篇文章也是这个思路,但用的是coding自带的持续集成功能,那么跟《Coding持续集成自动同步到GitHub》有什么区别呢?
区别还是有的,《Coding持续集成自动同步到GitHub》这篇文章用的还是需要在本地执行hexo g
命令生成好后,再通过git push
到Coding Pages
仓库,从而触发coding的持续集成自动同步到Github Pages
仓库。
这样,既可以通过coding的持续集成推送到coding pages仓库,再次触发coding pages的文件自动同步到github pages,就能做到一次更新完成两个节点
的部署。
coding申请与创建
首先注册coding,需要验证你手机号,这点没有github方便。然后新建一个项目,选择项目模板为代码托管项目即可。
项目名称随意,项目标志我这里命名为hexo-blog
,这个用来存放hexo g
后生成的静态网页文件,如果你已经有了,则不需要再创建。
然后点击代码仓库,快速初始化仓库,勾选启用README.md文件初始化仓库
后进行初始化。点击代码仓库
默认的就是你刚创建的这个仓库,点击右边靠上的克隆
记下你的地址,后面repo的时候会用到。
同样再次新建代码仓库
,不需要新建项目了,仓库名称我这里为hexo-source
,仓库类型为GIT仓库
,勾选启用 README.md 文件初始化项目
确认完成,这个是用来存放hexo的源文件,比如博客主题之类的hexo必须文件。
再次找到项目下的项目设置
,在左下角,点击进入项目与成员
→功能开关
,全部都开启它,在继续点击左侧的开发者选项
→项目令牌
→新建项目令牌
,令牌名称自己填写,过期时间自己酌情选择。
在代码仓库权限中为hexo-blog
勾选读写.推送至代码仓库
权限后新建令牌。记下令牌的用户名
和密码
。
上传代码
将Hexo源文件传入到hexo-source
仓库,源文件有如下文件和文件夹:
- scaffolds文件夹
- source文件夹
- themes文件夹
- _config.yml
- package.json
- package-lock.json
配置coding持续集成-方案1
配置_config.yml
文件,也可以先配置好在上传,也可以在coding上修改。
deploy:
type: git
repo: https://令牌用户名:访问令牌@e.coding.net/coding用户名/hexo-blog/hexo-blog.git
branch: master
其中e.coding.net/coding用户名/hexo-blog/hexo-blog.git
就是上面申请hexo-blog仓库克隆中的地址,不过这里去掉https://
加到@后面即可。
点击持续集成
→构建计划
→自定义构建过程
,代码仓库选择hexo-source
确定后,进入配置流程,选择文本编辑器
贴入下面代码。此时,你在hexo-source
更新文章会进行持续构建,然后push至hexo-blog
仓库。代码如有复制不便,移步到 https://gitee.com/ct2/web/blob/master/coding-ci-hexo.md
pipeline {
agent any
stages {
stage('检出') {
steps {
checkout([$class: 'GitSCM', branches: [[name: env.GIT_BUILD_REF]],
userRemoteConfigs: [[url: env.GIT_REPO_URL, credentialsId: env.CREDENTIALS_ID]]])
}
}
stage('构建') {
steps {
echo '构建中...'
sh 'node -v'
sh 'npm install -g hexo-cli'
sh 'npm install hexo --save'
sh 'npm install -g hexo-generator-searchdb'
sh 'npm install -g'
echo '构建完成.'
}
}
stage('测试') {
steps {
echo '单元测试中...'
sh 'hexo clean'
sh 'hexo g '
echo '单元测试完成.'
}
}
stage('部署') {
steps {
echo '部署中...'
sh 'npm install hexo-deployer-git --save'
sh 'hexo deploy'
echo '部署完成'
}
}
}
}
配置coding持续集成-方案2
在《配置coding持续集成-方案1》中,缺点是token以明文形式在日志中输出,而coding是支持提供环境变量保密配置的。
过程如下,把下面代码替换上面中的代码,然后参考《Coding持续集成自动同步到GitHub》中的 配置Coding-Ci
这一小节,即可完成配置。
pipeline {
agent {
docker {
registryUrl 'https://coding-public-docker.pkg.coding.net'
image 'public/docker/nodejs:12'
}
}
stages {
stage('检出') {
steps {
checkout([$class: 'GitSCM', branches: [[name: env.GIT_BUILD_REF]], userRemoteConfigs: [[url: env.GIT_REPO_URL, credentialsId: env.CREDENTIALS_ID]]])
}
}
stage('环境') {
steps {
echo '构建中...'
sh 'npm config set registry http://mirrors.cloud.tencent.com/npm/'
sh 'npm install'
sh 'node -v && npm -v'
sh 'npm install -g hexo-cli'
sh 'npm install hexo --save'
sh 'npm install -g hexo-generator-searchdb'
sh 'npm install -g'
sh 'hexo -v'
echo '构建完成.'
}
}
stage('生产') {
steps {
echo '生产中...'
sh 'hexo clean'
sh 'hexo g'
echo '生产完成.'
}
}
stage('部署') {
steps {
echo '部署中...'
dir(path: 'public') {
sh 'ls'
sh 'git init'
sh 'git config user.name $USER_NAME'
sh 'git config user.email $USER_EMAIL'
sh 'git add -A'
sh 'git commit -m "$GIT_COMMIT"'
sh 'git push -u -f "$USER_PROJECT" master:master'
}
echo '部署完成'
}
}
}
}
USER_NAME=填写你的名称;
USER_EMAIL=填写你的邮件;
USER_PROJECT=https://子账号名:子账号的密码@项目地址,其实就是方案1中_config.yml
配置文件中的 repo:
的地址 https://令牌用户名:访问令牌@e.coding.net/coding用户名/hexo-blog/hexo-blog.git
,此时你还可以删除_config.yml
配置中的repo等字段。
Coding代码托管SSH协议推送异常
博客最后一次文章更新已经是在半年前了,因这两天网站的SSL证书也到期了,上午才解决了SSL证书申请的问题,下午就遇见了Coding服务器的网络故障,就大半年更新一次,这么低频率的更新就刚好被我撞见。
因前两个月也更换了电脑,就一直没有配置相关的环境,有了昨日的证书更新,今天才有了点兴致去捣鼓这些。长时间没接触这些一种陌生有熟悉的感觉涌上心头,刚开始一直以为是自己的操作方法不对。后面还各种搜索,看了相关文章并没有解决问题。到后面我把coding的登录密码都修改了,此时web页面自动退出要求重新登录。
重新登录后才有了如下图所示,感情折腾了这么久,是官方的故障导致,但说是部分地区网络,机智如我立马切换网络试试,从电信切换为移动,而Git的命令行提示虽然有些许变化,但终究的错误还是一样的,大概结果都是Connection reset by 81.69.155.167 port 22 fatal: Could not read from remote repository.
。
虽然得到了官方的故障通知,但此时的我依旧是怀疑自己的问题,因为自己很久没有接触这玩意了,总感觉自己是哪里漏了一步所致,或者是Coding的策略变更而自己不知道。最终,随着时间的推进,问题自然而然的解决了,确实是Coding在这个地区的SSH协议推送异常所致。