Builds e releases pt BR

Builds e releases com GitHub Actions

Português (Brasil) · English · Início

Os workflows seguem o modelo de publicação manual Create Release usado pelo omp-cef. Atualmente, o omp-drip suporta apenas Windows x86.

Integração contínua

O workflow Build and Test roda em pushes para main, pull requests e execuções manuais. Ele executa os testes Node.js, compila a verificação da API Pawn com sampctl e open.mp, compila a DLL e o ASI na configuração Release, executa os testes nativos com asserções habilitadas, verifica a arquitetura PE e disponibiliza os arquivos da release como artefato do workflow por 14 dias.

A compilação usa um runner Windows 2022, Node.js 24 e os scripts existentes de preparação e compilação nativa. Não exige arquivos do GTA nem secrets adicionais.

Publicar uma versão

Com os arquivos do workflow na branch padrão do repositório:

1. Abra Actions > Create Release > Run workflow.
2. Selecione a branch ou tag que deseja compilar e informe uma versão, como 1.0.0, sem o prefixo v.
3. Aguarde a validação, compilação, testes e empacotamento. O workflow publica a release v1.0.0 e anexa os arquivos testados.

Como alternativa, envie uma tag de versão estável:

git tag v1.0.0
git push origin v1.0.0

Os dois caminhos compilam a revisão selecionada e publicam exatamente os artefatos resultantes. As execuções manuais criam a tag no commit compilado, caso ela ainda não exista. Uma tag existente deve apontar para esse mesmo commit. As versões devem seguir x.y.z, sem zeros à esquerda; versões já publicadas nunca são sobrescritas. Falhas no upload deixam um rascunho que pode ser retomado com a mesma revisão e versão.

Somente o job de publicação tem contents: write; os jobs de compilação e pull requests têm acesso de leitura ao repositório. O workflow usa o GITHUB_TOKEN automático do GitHub, sem precisar de token pessoal. As políticas do repositório ou da organização devem permitir que o Actions publique releases. O workflow gera notas de release e só publica após concluir o upload dos arquivos, usando os comandos de release do GitHub CLI.

Pacotes e manifesto

A release contém ZIPs versionados do servidor e do cliente para Windows x86, a DLL, o ASI, o include Pawn e um arquivo de checksums. O ZIP do servidor segue a estrutura components/ do open.mp. Esses binários são genéricos: arquivos do GTA e catálogos locais nunca fazem parte da compilação do CI nem dos arquivos da release.

O arquivo versionado src/generated/manifest.hpp deve permanecer sem configuração nas builds públicas. Nesse caso, o componente funciona em modo de desenvolvimento. Para exigir o pacote exato do cliente, gere seu catálogo, empacote os arquivos do cliente e recompile o servidor com o manifesto gerado, conforme o README.

Para criar os mesmos pacotes localmente:

./scripts/bootstrap-native.ps1
./scripts/build.ps1 -Configuration Release -Version 1.0.0
./scripts/package-release.ps1 -Version 1.0.0

Use o workflow de release para selecionar a versão informada pelo componente; alterar apenas o nome do arquivo compactado não altera a versão dentro do componente.