Développeurs · Recettes pour votre CI
Votre CI, déployant sur SWPanel
Copiez la recette de votre outil, enregistrez votre jeton comme secret et faites un push. SWPanel reçoit le paquet, le valide, l'analyse et le publie sur votre hébergement ou votre Cloud, avec une copie de l'existant.
- GitHub Actions, GitLab CI, Bitbucket et Jenkins
- Mode test pour les pull requests
- Retour en arrière en un appel
~/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]"Paquet reçu en entier ok SHA-256Validé ok chemins, taille et fichiersAnalysé ok sans erreur graveCopie de l'existant, enregistrée okPublié sur votre site ok
Avant de commencer
Trois choses et vous pouvez déployer
-
Créez un jeton dans SWPanel
Idéalement un jeton de déploiement uniquement, limité au service où vous publierez, avec expiration et vos IP.
-
Enregistrez-le comme secret
Dans votre CI, sous le nom
SWPANEL_TOKEN. Jamais dans le dépôt. -
Désignez le service
L'identifiant de l'hébergement ou du Cloud où vit votre site, dans la variable
SERVICIO.
Recettes
Choisissez votre outil, copiez-collez
Toutes font la même chose : elles construisent le site comme d'habitude, l'empaquettent et le téléversent avec un appel à l'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]"
# S'exécute à chaque push vers 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]"
# S'exécute à chaque push vers 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]"
# S'exécute à chaque push vers 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]"'
}
}
}
}
// Le jeton, enregistré comme identifiant 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]" # Depuis votre terminal ou n'importe quel 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]" # Votre thème, depuis le dépôt, sans toucher à wp-config.php ni aux téléversements
Recettes d'exemple. Toutes les options de l'appel (mode test, branche, commit et fichiers protégés) se trouvent dans la documentation de l'API.
Pull requests
Testez-le avant de fusionner
Avec le mode test, SWPanel valide et analyse le paquet de chaque pull request et vous dit ce qui se passerait, sans rien publier. Ainsi, ce qui arrive sur main a déjà passé le filtre.
- La même analyse qu'en production : erreurs, sécurité et dépendances
- Vos règles s'appliquent aussi : un Flux peut bloquer le déploiement
- Pas une seule ligne du site ne change
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"
# À chaque pull request : valide et analyse, sans publier
Ce qui se passe ensuite
De l'appel au site
Ce que fait SWPanel avec chaque paquet, avant de toucher à votre site.
-
Le reçoit
En entier : tant qu'il n'est pas arrivé complet et que son empreinte (SHA-256) ne correspond pas, il n'est pas utilisé.
-
Le valide
Chemins, taille (jusqu'à 50 Mo par défaut) et fichiers interdits.
-
L'analyse
Erreurs, vulnérabilités et dépendances présentant des failles connues.
-
Applique vos règles
Vos Flux peuvent arrêter un déploiement, et la production peut demander une approbation depuis SWPanel ou Telegram.
-
Le publie
Avec une copie de la version précédente et sans toucher à vos fichiers protégés. Vous et votre équipe recevez l'avis.
Sans secrets
Déployez sans stocker aucune clé
Avec OIDC, GitHub Actions et GitLab CI prouvent à SWPanel quel dépôt et quelle branche ils déploient. Il n'y a aucune clé dans le CI qui puisse fuiter.
Retour en arrière
Si quelque chose tourne mal, un clic
Chaque déploiement est enregistré dans l'historique : qui, quand, quel commit et ce qui a changé. Vous revenez à la version précédente en un clic dans SWPanel ou avec un appel à l'API, et les déploiements atomiques font basculer le site d'un coup, sans états intermédiaires.
Questions fréquentes
Questions sur les déploiements
Votre prochain push, déjà sur le site
Créez votre jeton, copiez la recette et faites un push.
