Novo na versão 0.4.22
Configurar CI para um repositório
Abra CI/CD na barra de navegação. Esta versão configura a integração contínua; ela não faz o deploy da sua aplicação.
Os nomes dos controles abaixo correspondem à interface em inglês.
Antes de começar
Um plano pago e um repositório com commits
Entre em Account com um plano pago; uma vaga em uma equipe paga Team, Business ou Enterprise conta, mas um período de teste não. A configuração precisa de um servidor Termiyo acessível com os modelos de CI da versão 0.4.22. Envie um primeiro commit ao repositório antes de configurar a CI.
11 tipos de projeto
Build it as oferece Node.js, Python, Go, Rust, Java (Maven), Java (Gradle), Ruby, PHP, .NET, Docker image e A blank starting point. A detecção do GitHub e do GitLab lê os nomes dos arquivos na raiz do repositório; confira a escolha e selecione uma opção se houver várias correspondências. O ponto de partida em branco contém uma etapa provisória para você substituir.
GitHub
1. Preparar um token
Escolha GitHub e clique em Open GitHub’s token page. Use um token de acesso pessoal com permissões específicas, limitado ao repositório: Contents, Workflows e Pull requests precisam de Read and write; Actions e Metadata precisam de Read. Defina uma validade de 90 dias ou menos. Só há suporte ao github.com, por meio de api.github.com; GitHub Enterprise não é compatível.
2. Salvar e verificar
Escolha Saved token ou clique em Save a new token, preencha Name e Paste the token e clique em Save to key box. Em Repository, digite owner/name ou o link do github.com e clique em Check. Você também pode usar List repositories this token can see.
3. Revisar e abrir a pull request
Escolha Build it as, clique em Show the file, revise o arquivo e clique em Set up CI. O Termiyo faz o commit de .github/workflows/termiyo-ci.yml em termiyo/ci-setup e abre uma pull request. Use Open in browser para revisar e fazer o merge. A CI pode rodar na pull request; a branch padrão fica inalterada até alguém fazer o merge.
GitLab
1. Informar o projeto e preparar um token
Escolha GitLab. Em Project, digite group/project para gitlab.com ou a URL HTTPS completa do projeto no seu próprio GitLab e clique em Open GitLab’s token page. Use um token de acesso pessoal ou de projeto com o escopo api; ele permite tudo que o proprietário pode fazer, então use uma validade curta e revogue o token após a configuração.
2. Verificar o projeto e os runners
Escolha Saved token ou use Save a new token → Save to key box e clique em Check. Escolha Build it as. Se não houver um runner disponível, ative os runners compartilhados ou registre um runner do projeto antes do merge; o painel também informa quando o token não permite determinar se há um runner disponível.
3. Revisar e abrir a merge request
Clique em Show the file, revise o arquivo e clique em Set up CI. O Termiyo faz o commit de .gitlab-ci.yml em termiyo/ci-setup e abre uma merge request. Use Open in browser para revisar e fazer o merge; a branch padrão fica inalterada até o merge.
Giti: Repos on a host
1. Verificar o host
Conecte ao host SSH que contém seu repositório Giti e escolha Repos on a host. Esse runner precisa de Linux em x86_64 ou ARM64, git e Docker utilizável pela conta SSH, além de curl ou wget, tar, sha256sum ou shasum e timeout. O Termiyo não instala o Docker; peça ao administrador do host ou use Docker sem root.
2. Instalar e ativar
Clique em Install the CI runner. O Termiyo baixa nektos/act 0.2.89 em ~/.termiyo/bin e verifica seu SHA-256 antes de descompactar ou executar. No repositório, escolha Build it as e clique em Turn CI on. Um hook post-receive existente de outra ferramenta é preservado e impede a configuração automática.
3. Fazer merge, push e ler o resultado
Se o Termiyo criou a branch do fluxo termiyo/ci, use Copy para copiar os comandos exibidos e execute-os no seu clone, na branch padrão, para fazer o merge e o push. O host passa a executar .github/workflows/termiyo-ci.yml com act em Docker após os pushes do proprietário; pushes de colegas com acesso concedido nunca iniciam a CI. Use Refresh e Log para ler os resultados e Turn CI off para desativar o hook.
Recursos do seu host
Cada execução tem um limite de 30 minutos. O Termiyo solicita ao Docker a rede bridge, nenhum socket Docker dentro do job, nenhum privilégio novo e limites de 2 CPUs, 4 GB de memória e 512 processos; o cumprimento depende do Docker do host. A primeira execução baixa uma imagem de 2,3 GB.
Limites e verificação
Fluxos existentes e planos
No GitHub e no GitLab, o Termiyo nunca sobrescreve o arquivo de fluxo de destino; se .gitlab-ci.yml já existe, oferece um modelo para integrar manualmente. O plano pago cobre a configuração pelo Termiyo: a leitura das execuções não depende do plano, e a CI já configurada continua rodando quando o plano termina. Os modelos vêm do servidor do Termiyo e precisam corresponder às impressões digitais fixadas no aplicativo.
Validação até agora
A configuração do GitHub e do GitLab foi testada com simulações, não com contas reais. O Giti CI concluiu uma execução real em um host x86_64. O deploy não está implementado nesta versão.