Developers · Receitas para o seu CI
Seu CI, implantando no SWPanel
Copie a receita da sua ferramenta, guarde o seu token como segredo e faça push. O SWPanel recebe o pacote, o valida, analisa e publica na sua hospedagem ou no seu Cloud, com uma cópia do que havia.
- GitHub Actions, GitLab CI, Bitbucket e Jenkins
- Modo de teste para as pull requests
- Volta atrás em uma chamada
~/mi-web npm run build && tar -czf web.tgz -C dist .~/mi-web curl -X POST …/services/$SERVICIO/deployment/ \ -H "Authorization: Bearer $SWPANEL_TOKEN" -F "[email protected]"Pacote recebido inteiro ok SHA-256Validado ok rotas, tamanho e arquivosAnalisado ok sem erros gravesCópia do que havia, salva okPublicado no seu site ok
Antes de começar
Três coisas e você já pode implantar
-
Crie um token no SWPanel
Melhor um só de implantação, limitado ao serviço onde você vai publicar, com validade e os seus IPs.
-
Guarde-o como segredo
No seu CI, com o nome
SWPANEL_TOKEN. Nunca no repositório. -
Aponte o serviço
O identificador da hospedagem ou do Cloud onde vive o seu site, na variável
SERVICIO.
Receitas
Escolha a sua ferramenta, copie e cole
Todas fazem o mesmo: constroem o site como sempre, empacotam e sobem com uma chamada à API.
on:
push:
branches: [main]
jobs:
desplegar:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci && npm run build && tar -czf web.tgz -C dist .
- run: |
curl -X POST \
https://api.swpanel.com/public/services/$SERVICIO/deployment/ \
-H "Authorization: Bearer ${{ secrets.SWPANEL_TOKEN }}" \
-F "[email protected]"
# Executa a cada push para main
desplegar:
stage: deploy
image: node:20
rules:
- if: $CI_COMMIT_BRANCH == "main"
script:
- npm ci && npm run build && tar -czf web.tgz -C dist .
- >
curl -X POST
"https://api.swpanel.com/public/services/$SERVICIO/deployment/"
-H "Authorization: Bearer $SWPANEL_TOKEN"
-F "[email protected]"
# Executa a cada push para main
image: node:20
pipelines:
branches:
main:
- step:
name: Desplegar en SWPanel
script:
- npm ci && npm run build && tar -czf web.tgz -C dist .
- curl -X POST "https://api.swpanel.com/public/services/$SERVICIO/deployment/"
-H "Authorization: Bearer $SWPANEL_TOKEN"
-F "[email protected]"
# Executa a cada push para main
pipeline {
agent any
environment { SWPANEL_TOKEN = credentials('swpanel-token') }
stages {
stage('Construir') {
steps { sh 'npm ci && npm run build && tar -czf web.tgz -C dist .' }
}
stage('Desplegar') {
when { branch 'main' }
steps {
sh 'curl -X POST "https://api.swpanel.com/public/services/$SERVICIO/deployment/" -H "Authorization: Bearer $SWPANEL_TOKEN" -F "[email protected]"'
}
}
}
}
// O token, guardado como credencial do Jenkins
tar -czf web.tgz -C dist . curl -X POST "https://api.swpanel.com/public/services/$SERVICIO/deployment/" \ -H "Authorization: Bearer $SWPANEL_TOKEN" \ -F "[email protected]" # A partir do seu terminal ou de qualquer script
composer install --no-dev tar -czf tema.tgz -C wp-content/themes/mi-tema . curl -X POST "https://api.swpanel.com/public/services/$SERVICIO/deployment/" \ -H "Authorization: Bearer $SWPANEL_TOKEN" \ -F "[email protected]" # Seu tema, a partir do repositório, sem mexer em wp-config.php nem nos uploads
Receitas de exemplo. Todas as opções da chamada (modo de teste, ramo, commit e arquivos protegidos) estão na documentação da API.
Pull requests
Teste antes de fazer o merge
Com o modo de teste, o SWPanel valida e analisa o pacote de cada pull request e diz o que aconteceria, sem publicar nada. Assim, o que chega a main já passou no filtro.
- A mesma análise da produção: erros, segurança e dependências
- As suas regras também se aplicam: um Fluxo pode vetar a implantação
- Nem uma linha do site muda
on: pull_request
jobs:
probar:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci && npm run build && tar -czf web.tgz -C dist .
- run: |
curl -X POST \
https://api.swpanel.com/public/services/$SERVICIO/deployment/ \
-H "Authorization: Bearer ${{ secrets.SWPANEL_TOKEN }}" \
-F "[email protected]" \
-F "dry_run=true"
# Em cada pull request: valida e analisa, sem publicar
O que acontece depois
Da chamada ao site
O que o SWPanel faz com cada pacote, antes de mexer no seu site.
-
Recebe
Inteiro: até chegar completo e a sua impressão digital (SHA-256) conferir, não é usado.
-
Valida
Rotas, tamanho (até 50 MB por padrão) e arquivos proibidos.
-
Analisa
Erros, vulnerabilidades e dependências com falhas conhecidas.
-
Aplica as suas regras
Os seus Fluxos podem parar uma implantação, e a produção pode pedir aprovação pelo SWPanel ou Telegram.
-
Publica
Com uma cópia do anterior e sem mexer nos seus arquivos protegidos. Você e a sua equipe recebem o aviso.
Sem segredos
Implante sem guardar nenhuma chave
Com OIDC, GitHub Actions e GitLab CI demonstram ao SWPanel qual repositório e qual ramo estão implantando. Não há nenhuma chave no CI que possa vazar.
Volta atrás
Se algo der errado, um clique
Cada implantação fica no histórico: quem, quando, qual commit e o que mudou. Você volta à versão anterior com um clique no SWPanel ou com uma chamada à API, e as implantações atômicas mudam o site de uma vez, sem estados intermediários.
Perguntas frequentes
Dúvidas sobre implantações
Seu próximo push, já no site
Crie o seu token, copie a receita e faça push.
