Files
backspace/docs/build-desktop.md
T
devsyncwrld f7f2cf75ab
OpenSSF Scorecard / Scorecard analysis (push) Waiting to run
CI / Build & test (Node 20) (push) Canceled after 0s
CI / Build & test (Node 24) (push) Canceled after 0s
CI / Build & test (push) Canceled after 0s
CodeQL / Analyze (javascript-typescript) (push) Canceled after 0s
Security / Secret scan (gitleaks) (push) Canceled after 0s
Security / Dependency scan (OSV-Scanner) (push) Canceled after 0s
Security / IaC/config scan (Trivy) (push) Canceled after 0s
Security / License compliance scan (Trivy) (push) Canceled after 0s
build(desktop): point releases at the fork and rebuild the new native module
release.yml already builds and publishes desktop installers for every platform
on a v* tag, so no new workflow was needed — it needed adapting to the fork.

electron-builder published to upstream's repository, so releases (and with them
the electron-updater feed, which had no source at all) went nowhere useful.

More consequential: postinstall ran electron-rebuild against uiohook-napi only.
electron-native-screenshare would have been compiled for Node's ABI rather than
Electron's and failed to load at runtime — and since the loader degrades
quietly by design, the symptom would have been screen sharing with no sound and
no error, which is the exact bug this module exists to fix.

Documented in docs/build-desktop.md, including why the build has to run on
GitHub (Gitea Actions provides no hosted runners, and the module needs MSVC)
and why the Windows runner stays pinned to windows-2022.
2026-09-01 13:10:10 -03:00

2.6 KiB

Gerar o instalador do app desktop

O workflow .github/workflows/release.yml (herdado do upstream) já compila para macOS, Windows e Linux e publica os instaladores como release. Ele dispara ao empurrar uma tag v*.

Não foi preciso escrever workflow novo — foi preciso adaptá-lo ao fork.

Por que GitHub e não Gitea

O Gitea desta instância não tem Actions habilitado, e mesmo habilitado ele não oferece máquinas hospedadas: seria preciso registrar um PC Windows como runner e mantê-lo ligado. O GitHub fornece runners Windows prontos, que é exatamente o que falta — o módulo nativo do compartilhamento de áudio usa WASAPI e só compila no Windows, com o compilador da Microsoft.

O Gitea continua sendo o repositório principal. O GitHub entra apenas como espelho para compilar.

Passos (uma vez)

  1. Criar um repositório no GitHub — o electron-builder.yml está apontado para devsyncwrld/backspace. Se o seu for outro nome, ajuste lá.
  2. Adicionar o espelho e empurrar:
    cd /opt/backspace
    git remote add github git@github.com:devsyncwrld/backspace.git
    git push github main
    
  3. Marcar uma versão e empurrar a tag — é ela que dispara a compilação:
    git tag v1.0.1 && git push github v1.0.1
    
  4. Os instaladores aparecem na aba Releases do GitHub em ~15 minutos.

O que isso resolve de quebra

O electron-updater já estava instalado no projeto mas sem feed — o app não se atualizava sozinho. Como o publish agora aponta para as releases do fork, o app passa a encontrar versões novas por conta própria. Ninguém do grupo precisa reinstalar na mão de novo.

Adaptações feitas para o fork

O quê Por quê
publish.ownerdevsyncwrld Apontava para o repositório do upstream
postinstall reconstrói também electron-native-screenshare Rodava electron-rebuild só no uiohook-napi. O módulo novo seria compilado para a ABI do Node em vez da do Electron e falharia ao carregar — e como o carregamento degrada em silêncio, o sintoma seria "compartilha sem som", sem erro visível
Nota sobre asarUnpack O uiohook-napi tem build/ excluído do asar porque distribui binários prontos. O módulo novo não distribui: build/Release/*.node é a única cópia e não pode ser excluída

Detalhe herdado que vale preservar

O runner do Windows está fixado em windows-2022, não windows-latest. O comentário no workflow explica: a imagem latest traz o Visual Studio 18, que o node-gyp embutido no electron-rebuild não detecta ("unknown version undefined"). Não mude isso sem testar.