wxsm's space
  • Nov 19, 2020

    Auto Changelog with GitLab

    上一篇博文 Integrate Renovate with GitLab 中介绍了为私有代码仓库与私有源提供依赖自动检测更新并发起 Merge Request 的方式。Renovate 可以自动通过 Release Notes 获取到版本之间的更新日志,并在 MR 中展示,这为执行合并的评审人提供了极大的便利。

    接下来需要解决另一个问题:如何为分散在各处的私有依赖自动生成更新日志?

  • Nov 09, 2020

    Integrate Renovate with GitLab

    企业项目群中往往会有部分代码逻辑需要公用,将其抽离作为公共包发布到私有源的做法是比较优雅的解决方式。但是这么做的话后期需要面临一个问题:当一个公共依赖包的使用者数量逐渐庞大的时候,如何保证当此包发布新版本时,所有使用者都能尽可能快地得到更新?

    传统的解决方案:

    1. 手工对所有项目逐个升级。这种办法相当繁琐,且容易产生遗漏,当项目数量足够庞大的时候,发布一次将会时相当痛苦的体验;
    2. 在依赖安装时指定版本为 latest。这种办法虽然能保证每次安装时都能得到最新版本,但是却有诸多弊端,如:
      1. 无法保证依赖的安全性,有可能一次更新不慎造成大面积的瘫痪;
      2. 对「依赖锁」不友好,如 yarn.lock 等。

    因此,如何使这个过程变得优雅,是一个亟待解决的问题。

  • Nov 02, 2020

    Publish using GitHub Action

    本文是一些 GitHub Actions 常用发布动作的总结。

    强烈建议将所有 Publish actions 分开执行,不要集中到一个 Workflow 内。原因是如果其中一个动作因为某些原因失败了,GitHub 目前只能重启整个 Workflow,而如果 Workflow 内某个 Job 已经成功了,那么该 Job 下一次执行必然是失败(因为此类任务一般不能对同一个版本号执行两次,发布成功一次以后第二次尝试将会被拒绝发布),因此这一个提交的 Workflow 将永远不可能成功。

    需要注意的是,以下所提到的 secrets.GITHUB_TOKEN 均是 GitHub Action 内置的 Access Token,无需自行创建。而其它 secrets 则需要在 项目主页 -> Settings -> Secrets 处创建。

  • Oct 26, 2020

    IDEA 为 Markdown 文件默认启用 SoftWrap

    应该 JetBrains 家的所有 IDE 都有这个配置。习惯了用 Markdown 写博客的人每次都要手动点一下 SoftWrap 挺烦的。后来发现了一个配置可以帮我省去这一步:

    打开设置,找到:Editor > General > Soft Wraps,将 Soft-wrap files 选项勾上即可。IDE 默认已经填上了 *.md; *.txt; *.rst; *.adoc,因此不需要再做别的事情。

    image

    这样一来,每次只要打开以上格式的文件,编辑器就会自动开启 SoftWrap,一劳永逸。

  • Oct 25, 2020

    记一次艰难的 Debug

    这是一次关于本博客的 Debug 经历,过程非常曲折。关键词:Vue / SSR / 错配

    不知道从哪篇博文开始,博客在直接从内页打开时,或者在内页刷新浏览器时,会报以下错误:

    app.73b8bd4d.js:8
    DOMException: Failed to execute 'appendChild' on 'Node': 
    This node type does not support this method.
    

    screenshot

    该错误:

    1. 只会在 build 模式出现;
    2. 只会在发布上 Github Pages 后出现;
    3. 只会在某些博文中出现;
    4. 只会在直接从链接进入该博文,或者在该博文页面刷新时出现。

    该错误带来的影响,会导致页面上的所有 JavaScript 功能全部失效,具体来说是与 Vue.js 相关的功能。如:导航链接(因为使用了 Vue-Router),评论框,一些依赖于 Vue.js 的 VuePress 插件,等等。

  • Oct 21, 2020

    自动化部署: 从脚本到 K8s

    k8-logo

    如果公司有专业运维,项目的部署上线过程一般来说开发者都不会接触到。但是很不幸,我所在的团队没有独立的运维团队,所以一切都得靠自己(与同事)。

    以下都只是工作中逐步优化得到的经验总结,并且只以 Node.js 程序部署为例。

  • Oct 12, 2020

    Cache Yarn in Github Actions

    在 CI 中缓存安装下来的依赖项是提速的关键,Github Actions 官方文档 提供了如下方案 (NPM):

  • Oct 10, 2020

  • Sep 23, 2020

    Gitlab CE Code-Review Bot

    gitlab-logo

    由于 Gitlab CE 做代码评审时缺少了关键的评审员功能(详情参考此 issue),因此在使用 CE 的同时又想要做代码评审的话,就必须要自己想办法了。

    网上能找到的最多的解决方案就是在 Gitlab 前面再部署一套 Gerrit,通过拦截推送的代码以及同步两个库来实现。但是这种方案有诸多弊端。比如:

    1. 割裂的用户体验。原本习惯了使用 Gitlab 系统的人,要开始学习晦涩难懂的 Gerrit;
    2. 代码同步的不稳定性和不确定性。系统每增加一层逻辑,可靠性就降低一些;
    3. 复杂的使用方式:代码必须要从 Gerrit clone,同时 push 时分支名必须加上 refs 前缀,否则无法进入评审
    4. ...

    总体来说,以上的种种原因让我觉得 Gerrit 并不是最好的解决方案。对于凡事追求完美的处女座的我来说,我想要的东西大概应该具备以下几点:

    1. 最好是能直接在 Gitlab 上面进行评审。因为 CE 可以说是万万事俱备,只差流程;
    2. 最好是对原 Git 和 Gitlab 使用流程、习惯没有任何更改和侵入,仅增加评审流程;
    3. 最好是可以可以自动化整个流程(评审人自动分配、评审完自动合并,等等)。

    好在,Gitlab 有一套完备的 Web hook 以及 API 系统,可以支撑起我的想法。

  • Jul 17, 2020

    WSL on Windows 10 and Node.js

    Linux 的命令行与构建工具一般来说要比 Windows 好用,但 Windows 的用户界面毫无疑问要比 Linux 好用。以往在 Windows 10 上安装 Linux,要么是使用虚拟机,要么是使用双系统,总是无法做到两头兼顾。现在 Windows 10 有了 WSL 技术,使得「二者合一」成为了可能。

Older  →