GitHub Action for building and releasing Electron apps
This is a GitHub Action for automatically building and releasing your Electron app using GitHub's CI/CD capabilities. It uses electron-builder
to package your app and release it to a platform like GitHub Releases.
GitHub Actions allows you to build your app on macOS, Windows and Linux without needing direct access to each of these operating systems.
-
Install and configure
electron-builder
(v22+) in your Electron app. You can read about this in the project's docs or in my blog post. -
If you need to compile code (e.g. TypeScript) or run scripts before your app can be built, make sure this is done using a
build
script in yourpackage.json
file. This action will run that script before packaging your app. However, make sure that thebuild
script does not runelectron-builder
, as this action will do that for you. -
If you are building for macOS, you'll want your code to be signed. GitHub Actions therefore needs access to your code signing certificates:
- Open the Keychain Access app or the Apple Developer Portal. Export all certificates related to your app into a single file (e.g.
certs.p12
) and set a strong password - Base64-encode your certificates using the following command:
base64 -i certs.p12 -o encoded.txt
- In your project's GitHub repository, go to Settings → Secrets and add the following two variables:
mac_certs
: Your encoded certificates, i.e. the content of theencoded.txt
file you created beforemac_certs_password
: The password you set when exporting the certificates
The same goes for Windows code signing (
windows_certs
andwindows_certs_password
secrets). - Open the Keychain Access app or the Apple Developer Portal. Export all certificates related to your app into a single file (e.g.
-
Add a workflow file to your project (e.g.
.github/workflows/build.yml
):name: Build/release on: push jobs: release: runs-on: ${{ matrix.os }} # Platforms to build on/for strategy: matrix: os: [macos-10.14, windows-2019, ubuntu-18.04] steps: - name: Check out Git repository uses: actions/checkout@v1 - name: Install Node.js, NPM and Yarn uses: actions/setup-node@v1 with: node-version: 10 - name: Build/release Electron app uses: samuelmeuli/action-electron-builder@v1 with: # GitHub token, automatically provided to the action # (No need to define this secret in the repo settings) github_token: ${{ secrets.github_token }} # macOS code signing certificate mac_certs: ${{ secrets.mac_certs }} mac_certs_password: ${{ secrets.mac_certs_password }} # If the commit is tagged with a version (e.g. "v1.0.0"), # release the app after building release: ${{ startsWith(github.ref, 'refs/tags/v') }}
Using this the workflow above, GitHub will build your app every time you push a commit.
When you want to create a new release, follow these steps:
- Update the version in your project's
package.json
file (e.g.1.2.3
) - Commit that change (
git commit -am v1.2.3
) - Tag your commit (
git tag v1.2.3
). Make sure your tag name's format isv*.*.*
. Your workflow will use this tag to detect when to create a release - Push your changes to GitHub (
git push && git push --tags
)
After building successfully, the action will publish your release artifacts. By default, a new release draft will be created on GitHub with download links for your app. If you want to change this behavior, have a look at the electron-builder
docs.
If you are building/releasing your Linux app for Snapcraft (which is electron-builder
's default), you will additionally need to install and sign in to Snapcraft. This can be done using an action-snapcraft
step before the action-electron-builder
step:
- name: Install Snapcraft
uses: samuelmeuli/action-snapcraft@v1
# Only install Snapcraft on Ubuntu
if: startsWith(matrix.os, 'ubuntu')
with:
# Log in to Snap Store
snapcraft_token: ${{ secrets.snapcraft_token }}
You can read here how you can obtain a snapcraft_token
.
For an example of the action used in production (including app notarization and publishing to Snapcraft), see Mini Diary.
Suggestions and contributions are always welcome! Please discuss larger changes via issue before submitting a pull request.