Rebuilding dependencies take forever

[Imagineee]

When my build run it installs everything and runs fine but when it comes to building, it starts to rebuild native dependencies and does that forever untill github stops the action because of running for more than 6 hours.

It is rebuilding glasstron and node-pty and to add it runs perfectly fine on my windows 10 computer.

[Daniel Scalzi]

Can verify. This action is pretty much unusable with this issue.

[Aitor]

same here, in my case it also fails on my computer with Windows 11 WSL so I think it's an issue related to the electron-builder package

[Imagineee]

same here, in my case it also fails on my computer with Windows 11 WSL so I think it's an issue related to the electron-builder package

i have wsl but never tried it , but running the command on a remote linux instance like gitpod, electron builder works. it maybe the environment is not setup right for node gyp https://github.com/nodejs/node-gyp#on-unix

[Pilfer]

I also just started randomly experiencing this issue after adding a node module that had a native dependency (found by running find node_modules -type f -name "*.node" 2>/dev/null | grep -v "obj\.target" in my project directory).

I'm building for arm64, x64 on Mac and a universal NSIS for windows.

mac:
  target:
  - target: zip
    arch: arm64
  - target: zip
    arch: x64
  - target: dmg
    arch: x64
  - target: dmg
    arch: arm64
win:
  target:
  - target: nsis
    arch:
    - x64
    - ia32

In my case, I am using electron-builder v22.14.13 and a module that has an optional native dependency. I ended up forking this repo/action and added --no-optional to npm install. I also forked the offending module with the native optional dependency and removed said optional native dependency.

My builds are now succeeding, as is notarization and publishing after doing the above. Obviously this isn't an amazing solution for the actual problem, but it did allow me to get the app to production.

Side question: when utilizing this Action should we be explicitly noting the version to use? The README example has uses: samuelmeuli/action-electron-builder@v1 but I see the latest release is v1.6.0.

[Pilfer]

@d3v0ps

same here, in my case it also fails on my computer with Windows 11 WSL so I think it's an issue related to the electron-builder package

I'm sure you've already tried it, but have you made sure to delete your node_modules directory and re-run npm install directly from a WSL terminal? I've run into issues in the past when native modules for the wrong arch or OS are hanging around because I accidentally ran the install command in the wrong environment.

[Imagineee]

@d3v0ps

same here, in my case it also fails on my computer with Windows 11 WSL so I think it's an issue related to the electron-builder package

I'm sure you've already tried it, but have you made sure to delete your node_modules directory and re-run npm install directly from a WSL terminal? I've run into issues in the past when native modules for the wrong arch or OS are hanging around because I accidentally ran the install command in the wrong environment.

That's true, but not sure why it won't work in the actions, for Ubuntu, Windows and Mac os at the same time

[Thomas E Wilson]

I don't think a resolution was ever provided, here's mine. I also found that action-electron-builder hangs when trying to build native dependencies (e.g., node-pty). With all props to action-electron-builder, which has been useful to many, I think the best answer now is that you don't need it - just write what you need into your Action YAML.

Below are essential details of the two files needed to create a GitHub Action that:

• executes when package.json (and thus the app version) changes
• uses npm to build electron on whatever OS you choose to include
• compiles native dependencies correctly
• uses the appropriate signing certificates you saved as secrets for each platform

I have tested everything EXCEPT the signing certificates, but that's how you set those environment variables into the two conditional "run" steps.

package.json

{
  "version": "v0.0.0",
  "scripts": {
    "release": "electron-builder --publish always"
  },
  "devDependencies": {
    "electron": "^19.0.10",
    "electron-builder": "^23.1.0"
  },
  "build": {
    "win": {
      "publish": "github"
    },
    "mac": {
      "publish": "github"
    }
  }
}

.github/workflows/electron-builder.yml

name: "Electron Builder"
on:
  push:
    paths:
      - 'package.json' # only release when version changes
  workflow_dispatch: # allow manual triggering of action
env:
  GH_TOKEN: ${{ secrets.github_token }} # allow electron-builder to publish a draft release
jobs:
  ci:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [macos-latest, windows-latest] # add ubuntu-latest if needed
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 16
          cache: 'npm'
      - run: npm clean-install
      # - run: npm run build # if you need it
      - name: Run npm run release (Windows) # only executes on windows-latest
        if: runner.os == 'Windows'
        env: 
          CSC_LINK: ${{ secrets.win_certs }}
          CSC_KEY_PASSWORD: ${{ secrets.win_certs_password }}
        run: npm run release
      - name: Run npm run release (macOS) # only executes on macos-latest
        if: runner.os == 'macOS'
        env: 
          CSC_LINK: ${{ secrets.mac_certs }}
          CSC_KEY_PASSWORD: ${{ secrets.mac_certs_password }}
        run: npm run release

This screenshot shows how you get one job per OS where only the relevant 'release' step executes.

Thanks to action-electron-builder - some of these details were gleaned by reading its index.js file.

[Imagineee]

I just remember I recently wrote my own github action based on electron builder as if I was running it on my native machine.

you can run electron-builder --publish always and provide your github secret like this:

env:
  GH_TOKEN: ${{ secrets.GH_TOKEN }}

I haven't tried it with the original project the issue was with, but it should work.

This makes a draft release with all the files put in the release, so just add the description to the release and publish.

here is the custom action I wrote.

[Imagineee]

so, for anyone with this issue read @wilsonte-umich comment on this issue