家喻户晓,Electron 是一个开源的跨平台框架,它外部集成了 Node.js 环境和浏览器环境,让开发者能够应用 Web 技术来绘制客户端的 UI,同时领有不错的 I/O 能力。
咱们团队的产品 Eoapi 就应用了 Eletron 作为产品的基座,在公布时,须要针对 Windows、Mac 两个平台进行打包和构建,而 Mac 又分为 x86 以及 arm 两种处理器架构。
因而咱们最开始须要筹备三台电脑,用于构建三个平台的利用。
在本地打包,除了环境上的不便外,还会造成一些外乡特色的问题,例如因为平凡的长城造成的网络问题。
因而咱们心愿用自动化的形式进行构建,因为咱们的我的项目源码放在 Github 上,咱们很天然会选用 Github Action 来进行这个工作。
配置文件地址:https://github.com/eolinker/e…
能够关上配合本文食用~
首先咱们要在我的项目的根目录中建一个 .github
文件夹,其中有一个 workflows
文件夹,其中蕴含一个 release.yml
文件,这个文件名能够随便定义。
在 release.yml
中应用的是 yml
语法,能够将它了解为另一种格调的 JSON
,至多在表达力上,两者是近似的。如果须要具体理解,能够去看 GitHub Actions
的工作流程语法 – GitHub Docs
name: Release
on:
push:
tags:
- 'v*.*.*'
咱们定义的是通过 git tag
来触发这个自动化工作流。如果须要,也能够定义成依据某个分支提交的事件来触发。
接下来是定义具体的工作流程,以下是略微简化过的 Windows 环境构建,大抵定义了根底环境的定义,比方 Windows 零碎 + Node.js 16:
......
jobs:
release:
name: build and release Electron app
runs-on: ${{matrix.os}}
strategy:
fail-fast: false
matrix:
os: [windows-latest]
steps:
- name: Check out git repository
uses: actions/checkout@v3.0.0
- name: Install Node.js
uses: actions/setup-node@v3.0.0
with: node-version: '16'
- name: Release for Windows
if: matrix.os == 'windows-latest'
run: yarn release
env:
GITHUB_TOKEN: ${{secrets.GH_TOKEN}}
其中波及的上下文能够参考官网文档:上下文 – GitHub Docs。
咱们须要定义好一个 Electron-builder.json
搁置在根目录下,这外面配置一下打包的根本信息,因为这跟 Github Action
关系不大,这里不详细描述,总之这是 Electron
构建时的一个必要文件,这个文件可能会依赖的其余文件,须要本人依据我的项目状况进行配置。例如 ***.mac.plist
这类文件只给 MacOS
打包用的配置文件。
Windows 比较简单,根本只有定义好零碎和 Node.js 版本,如果你在本人的 Windows 电脑上构建没问题,那么在 Github Action 上遇到问题的概率也不大。
咱们在尝试 Github Action 上构建 Windows 利用,试了一两次也就胜利了,难在 MacOS 平台的构建。
如果你心愿公布后的 MacOS 利用,在用户装置时不会弹出不信赖的正告、以及可能自动更新,那必须要进行签名。
须要去苹果开发者账号上下载相应的证书,在本地构建的时候,Electron
会主动去找本地的钥匙串中找适合的证。那么在 Github Action
这样的云端环境怎么办呢?
简略地说,分为以下两步:
- 须要当时用命令行工具或其余工具,将证书转成 base64 寄存在 Github secrets 中。
- 在云端构建的时候,从 Github secrets 中取出 base64 字符串,解码后写入到运行时的环境变量中。
整个机制就是这样,运行时转换秘钥的语句如下:
run: |
CERTIFICATE_PATH=$RUNNER_TEMP/build_certificate.p12
echo -n "$BUILD_CERTIFICATE_BASE64" | base64 --decode --output $CERTIFICATE_PATH
咱们的利用有两个证书和一个密钥,因而写起来比拟繁琐,但关键点在上文中曾经提及,就是将文件转成 base64
寄存在 Github secrets
中,用时再取出。
具体的例子能够看:在用于 Xcode 开发的 macOS 运行器上装置 Apple 证书 – GitHub Docs,外面的阐明不算特地详尽,但根本包罗万象了。
难度次要在于,在运行时须要长期转换、生成多个文件,波及的环境变量较多,稍微费劲,其实逻辑并不简单。
如果在构建过程中遇到问题,能够在线查看输出日志来排查:
在本地构建时,Electron 会主动依照以后零碎的架构打包,例如我用本人的 MacBook M1 不必任何多余的配置就能构建出 arm 架构的利用。
但在 Github Action,因为 Github 提供的 MacOS 运行容器都是 x86,因而 须要显式申明构建 arm 的利用,咱们是这样通过构建命令指定的:
Electron-builder -m=dmg --arm64 -p onTagOrDraft
也就是说,在 Github Action 的 MacOS 环境中,咱们须要运行两次不一样的构建命令,以此失去两个平台的安装包,生成一个 Draft Release。
公布后的成果如图:
整个过程大体如此,具体的场景利用,能够参照咱们目前的开源我的项目 Eoapi 的构建配置。
很感激 Github Action 收费提供了这么一个运行环境。
Eoapi 是一款类 Postman 的 开源 API 工具 ,它更轻量,同时可拓展。
我的项目地址: https://github.com/eolinker/e…
文档地址: https://docs.eoapi.io/?utm_so…
官网地址: https://www.eoapi.io/
如果你对于 Eoapi 有任何疑难或者倡议,都能够去 Github 或者来这里找我,提个 Issue,我看到了都会及时回复的。