Developers · Recetas para tu CI
Tu CI, desplegando en SWPanel
Copia la receta de tu herramienta, guarda tu token como secreto y haz push. SWPanel recibe el paquete, lo valida, lo analiza y lo publica en tu hosting o en tu Cloud, con una copia de lo que había.
- GitHub Actions, GitLab CI, Bitbucket y Jenkins
- Modo prueba para las pull requests
- Vuelta atrás en una llamada
~/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]"Paquete recibido entero ok SHA-256Validado ok rutas, tamaño y ficherosAnalizado ok sin errores gravesCopia de lo que había, guardada okPublicado en tu web ok
Antes de empezar
Tres cosas y ya puedes desplegar
-
Crea un token en SWPanel
Mejor uno solo de despliegue, limitado al servicio donde vas a publicar, con caducidad y tus IPs.
-
Guárdalo como secreto
En tu CI, con el nombre
SWPANEL_TOKEN. Nunca en el repositorio. -
Apunta el servicio
El identificador del hosting o del Cloud donde vive tu web, en la variable
SERVICIO.
Recetas
Elige tu herramienta, copia y pega
Todas hacen lo mismo: construyen la web como siempre, la empaquetan y la suben con una llamada a la 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]"
# Se ejecuta en cada push a 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]"
# Se ejecuta en cada push a 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]"
# Se ejecuta en cada push a 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]"'
}
}
}
}
// El token, guardado como credencial de 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]" # Desde tu terminal o desde cualquier 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]" # Tu tema, desde el repositorio, sin tocar wp-config.php ni las subidas
Recetas de ejemplo. Todas las opciones de la llamada (modo prueba, rama, commit y ficheros protegidos) están en la documentación de la API.
Pull requests
Pruébalo antes de fusionar
Con el modo prueba, SWPanel valida y analiza el paquete de cada pull request y te dice qué pasaría, sin publicar nada. Así, lo que llega a main ya ha pasado el filtro.
- El mismo análisis que en producción: errores, seguridad y dependencias
- Tus reglas también se aplican: un Flujo puede vetar el despliegue
- Ni una línea de la web cambia
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"
# En cada pull request: valida y analiza, sin publicar
Qué pasa después
De la llamada a la web
Lo que hace SWPanel con cada paquete, antes de tocar tu web.
-
Lo recibe
Entero: hasta que no llega completo y cuadra su huella (SHA-256), no se usa.
-
Lo valida
Rutas, tamaño (hasta 50 MB por defecto) y ficheros prohibidos.
-
Lo analiza
Errores, vulnerabilidades y dependencias con fallos conocidos.
-
Aplica tus reglas
Tus Flujos pueden parar un despliegue, y producción puede pedir aprobación desde SWPanel o Telegram.
-
Lo publica
Con una copia de lo anterior y sin tocar tus ficheros protegidos. Tú y tu equipo recibís el aviso.
Sin secretos
Despliega sin guardar ninguna clave
Con OIDC, GitHub Actions y GitLab CI demuestran a SWPanel qué repositorio y qué rama están desplegando. No hay ninguna clave en el CI que se pueda filtrar.
Vuelta atrás
Si algo sale mal, un clic
Cada despliegue queda en el historial: quién, cuándo, qué commit y qué cambió. Vuelves a la versión anterior con un clic en SWPanel o con una llamada a la API, y los despliegues atómicos cambian la web de golpe, sin estados a medias.
Preguntas frecuentes
Dudas sobre despliegues
Tu próximo push, ya en la web
Crea tu token, copia la receta y haz push.
