devsyncwrld
d208b0c277
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)
- Criar um repositório no GitHub — o
electron-builder.ymlestá apontado parasyncwrld/resenhacord. Se o seu for outro nome, ajuste lá. - Adicionar o espelho e empurrar:
cd /opt/backspace git remote add github git@github.com:syncwrld/resenhacord.git git push github main - 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 - 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.