devsyncwrld
2f836cd366
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
57 lines
2.6 KiB
Markdown
57 lines
2.6 KiB
Markdown
# 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
|
|
`syncwrld/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:syncwrld/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.owner` → `syncwrld` | 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.
|