Bxio
febc807ad9
All checks were successful
Testar e publicar imagem Docker / publish (push) Successful in 15s
This reverts commit 282ba08c818b057c65bb06849383fb3fc855aed8.
49 lines
3.4 KiB
Markdown
49 lines
3.4 KiB
Markdown
# Gitea Actions → imagem Docker → Portainer Web editor
|
|
|
|
## 1. Ativar Actions no repositorio
|
|
|
|
No repositorio ts6-botflow, Configuracoes → Unidades (ou Avancado), ativar Actions. Nao e preciso alterar o servidor Gitea se Actions ja estiver disponivel.
|
|
|
|
## 2. Registar o runner
|
|
|
|
No mesmo repositorio, Configuracoes → Actions → Runners → Criar novo runner. Copiar o token de registo do **repositorio**, para limitar este runner ao ts6-botflow.
|
|
|
|
No Portainer, criar stack `ts6-botflow-runner` no Web editor e colar `runner-stack.yaml`. Adicionar variavel `RUNNER_TOKEN` com o token de registo. Fazer deploy. O runner deve aparecer Online no Gitea com a label `botflow-docker`.
|
|
|
|
O runner usa o socket Docker para construir as imagens. Os workflows deste repositorio podem controlar o Docker dessa maquina; manter a escrita no repositorio limitada a pessoas de confianca. O runner nao precisa de portas publicadas. Se o Docker estiver num LXC sem permissoes para Docker-in-Docker, esta configuracao usa o daemon ja existente.
|
|
|
|
## 3. Autorizar a publicacao da imagem
|
|
|
|
Na conta Gitea com acesso de escrita aos packages de `oixb.run`, Definicoes → Aplicacoes → Gerar token. Permissao `write:package` (inclui leitura). Nao reutilizar o segredo Discord nem o token de registo do runner.
|
|
|
|
No repositorio, Configuracoes → Actions → Secrets, criar:
|
|
|
|
- `REGISTRY_USER`: nome de login da conta Gitea dona do token. Se `oixb.run` for uma organizacao, usar a conta membro com permissao de escrita aos seus packages.
|
|
- `REGISTRY_TOKEN`: token pessoal criado acima.
|
|
|
|
Os tokens ficam nas configuracoes Gitea/Portainer, nunca no Git.
|
|
|
|
## 4. Fazer o primeiro build
|
|
|
|
Abrir Actions → Testar e publicar imagem Docker → Run workflow, branch main. Se nao aparecer o botao, enviar um novo commit para main ou repetir a execucao que ficou pendente apos o envio do workflow.
|
|
|
|
O workflow instala as ferramentas no job, obtem o commit, executa os testes de autenticacao numa etapa Docker Node 22 e constroi/publica a imagem. O log so deve mostrar publicacao depois de os testes passarem. Sao criadas tags `latest` e o SHA completo do commit.
|
|
|
|
Imagem: `gitea.zol.oixb.run/oixb.run/ts6-botflow:latest`.
|
|
|
|
## 5. Arrancar o bot no Web editor
|
|
|
|
Esperar pelo primeiro workflow verde. Se o package for privado, adicionar em Portainer → Registries → Add registry → Custom registry o dominio `gitea.zol.oixb.run`, com uma conta/token que tenha `read:package`. Dar acesso ao ambiente Docker se o Portainer o pedir.
|
|
|
|
Criar stack `ts6-botflow`, colar `bot-stack.yaml` e adicionar `DISCORD_CLIENT_SECRET` nas variaveis de ambiente. Fazer deploy. Abrir http://192.168.88.99:3080.
|
|
|
|
## Atualizacoes
|
|
|
|
Cada push em main testa, constroi e publica uma imagem. A stack Web editor nao e atualizada apenas pelo push: no Portainer fazer Update the stack com a opcao de voltar a descarregar a imagem e recriar o container. `pull_policy: always` pede o download em cada deploy. Restart sozinho nao descarrega uma imagem nova.
|
|
|
|
A automatizacao de deployment pode ser adicionada depois com webhook Portainer, se essa funcao estiver disponivel na edicao instalada. Esta versao automatiza o build e a publicacao, nao o deployment. O volume preserva os dados quando o container e recriado.
|
|
|
|
## Validacao
|
|
|
|
As stacks e o workflow sao verificados localmente. O build real e o login no registry so podem ser confirmados depois de registar o runner e configurar os secrets. As imagens Docker nao sao publicadas apenas por enviar este ficheiro.
|