Sviluppatori · Ricette per il tuo CI
Il tuo CI, che distribuisce su SWPanel
Copia la ricetta del tuo strumento, salva il tuo token come segreto e fai push. SWPanel riceve il pacchetto, lo convalida, lo analizza e lo pubblica sul tuo hosting o sul tuo Cloud, con una copia di ciò che c'era.
- GitHub Actions, GitLab CI, Bitbucket e Jenkins
- Modalità di prova per le pull request
- Ritorno indietro in una chiamata
~/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]"Pacchetto ricevuto per intero ok SHA-256Convalidato ok percorsi, dimensioni e fileAnalizzato ok senza errori graviCopia di ciò che c'era, salvata okPubblicato sul tuo sito ok
Prima di iniziare
Tre cose e puoi già distribuire
-
Crea un token in SWPanel
Meglio uno solo di deploy, limitato al servizio dove pubblicherai, con scadenza e i tuoi IP.
-
Salvalo come segreto
Nel tuo CI, con il nome
SWPANEL_TOKEN. Mai nel repository. -
Indica il servizio
L'identificativo dell'hosting o del Cloud in cui vive il tuo sito, nella variabile
SERVICIO.
Ricette
Scegli il tuo strumento, copia e incolla
Tutte fanno lo stesso: costruiscono il sito come sempre, lo impacchettano e lo caricano con una chiamata all'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]"
# Viene eseguito a ogni push su 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]"
# Viene eseguito a ogni push su 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]"
# Viene eseguito a ogni push su 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]"'
}
}
}
}
// Il token, salvato come credenziale di 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]" # Dal tuo terminale o da qualsiasi 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]" # Il tuo tema, dal repository, senza toccare wp-config.php né i caricamenti
Ricette di esempio. Tutte le opzioni della chiamata (modalità di prova, ramo, commit e file protetti) sono nella documentazione dell'API.
Pull request
Provalo prima di unire
Con la modalità di prova, SWPanel convalida e analizza il pacchetto di ogni pull request e ti dice cosa succederebbe, senza pubblicare nulla. Così, ciò che arriva su main ha già superato il filtro.
- La stessa analisi della produzione: errori, sicurezza e dipendenze
- Anche le tue regole si applicano: un Flusso può bloccare il deploy
- Nemmeno una riga del sito 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"
# A ogni pull request: convalida e analizza, senza pubblicare
Cosa succede dopo
Dalla chiamata al sito
Ciò che SWPanel fa con ogni pacchetto, prima di toccare il tuo sito.
-
Lo riceve
Per intero: finché non arriva completo e la sua impronta (SHA-256) non quadra, non viene usato.
-
Lo convalida
Percorsi, dimensioni (fino a 50 MB per impostazione predefinita) e file vietati.
-
Lo analizza
Errori, vulnerabilità e dipendenze con difetti noti.
-
Applica le tue regole
I tuoi Flussi possono fermare un deploy, e la produzione può richiedere approvazione da SWPanel o Telegram.
-
Lo pubblica
Con una copia del precedente e senza toccare i tuoi file protetti. Tu e il tuo team ricevete l'avviso.
Senza segreti
Distribuisci senza salvare nessuna chiave
Con OIDC, GitHub Actions e GitLab CI dimostrano a SWPanel quale repository e quale ramo stanno distribuendo. Non c'è nessuna chiave nel CI che possa trapelare.
Ritorno indietro
Se qualcosa va storto, un clic
Ogni deploy resta nello storico: chi, quando, quale commit e cosa è cambiato. Torni alla versione precedente con un clic in SWPanel o con una chiamata all'API, e i deploy atomici cambiano il sito di colpo, senza stati intermedi.
Domande frequenti
Dubbi sui deploy
Il tuo prossimo push, già sul sito
Crea il tuo token, copia la ricetta e fai push.
