Ne publier qu’un paquet testé

ShellBeginner
Pratiquer maintenant

Introduction

FIELDNOTES dispose d'un bon test visiteur, mais son script local peut continuer après un échec et publier un autre paquet. Vous devez relier la décision au contenu réellement livré.

Ce nouvel environnement contient les contrôles terminés du premier laboratoire et le site publié inchangé. Vous réparerez un petit pipeline Bash, rejetterez une entrée défectueuse, publierez une entrée valide et montrerez qu'une modification ultérieure des brouillons ne change pas le paquet enregistré. Les onglets Workstation, Live Website et Candidate Preview sont prêts. Il s'agit d'un pipeline local d'apprentissage, pas de GitHub Actions ni d'une barrière de sécurité de production.

Faire arrêter la publication par un échec

Dans cette étape, vous transmettrez un même argument candidat au test puis à la publication. Commencez dans Live Website. Ouvrez l'exposition, Plan your visit et le téléchargement visiteur. L'entrée actuelle est East gate. Revenez à l'accueil avec FIELDNOTES.

Passez dans Workstation. cat affiche le pipeline fourni :

cat pipeline.sh

Le script initial lance un contrôle, puis essaie de publier le paquet fixe packages/candidate.tar.gz. Des lignes indépendantes continuent même si la précédente échoue. Le publicateur refuse lui-même un paquet non testé ; vous devez aussi faire échouer le pipeline et transmettre l'entrée voulue aux deux étapes.

Bash conserve le premier argument dans $1. candidate="$1" l'enregistre dans une variable. "$candidate" développe cette valeur en un seul argument, même si le chemin contient des espaces. && n'exécute la commande suivante que si la précédente se termine avec le statut zéro. Zéro signifie réussite ; une autre valeur signifie échec. La dernière commande exécutée détermine le résultat de ce petit script.

Remplacez tout le script avec le here-document appris au premier laboratoire. Le dernier BASH termine le bloc littéral :

cat > pipeline.sh <<'BASH'
#!/bin/bash
candidate="$1"
python3 tools.py check "$candidate" &&
python3 tools.py publish "$candidate"
BASH

#!/bin/bash désigne l'interpréteur. Vous utiliserez explicitement bash, donc aucune modification du droit d'exécution n'est nécessaire. Les deux commandes reçoivent exactement le même argument de paquet. N'ajoutez pas || true, ne retirez pas les contrôles et ne remplacez pas l'argument par un bon paquet fixe.

Testez un mauvais candidat ; cet échec est intentionnel :

bash pipeline.sh packages/wrong.tar.gz

Attendez FAIL: Wrong visitor guide content, sans ligne Published. Consultez immédiatement le statut : $? est le statut de sortie de la commande précédente et echo l'affiche. Exécutez ceci séparément, juste après le pipeline :

echo $?

Attendez 1. Une commande intermédiaire remplacerait ce statut. Dans Live Website, rechargez et suivez les liens de visite et de téléchargement : la référence saine reste disponible. Un refus de publication doit laisser le service fonctionner.

En cas d'erreur de syntaxe Bash, relisez le fichier enregistré et rétablissez la recette affichée. Un script cassé ne démontre pas un contrôle de publication efficace. L'étape suivante montrera qu'il accepte aussi une entrée valide.

Publier le paquet testé

Dans cette étape, vous publierez un candidat valide et distinguerez les octets du paquet enregistré d'une copie de travail modifiable. Commencez dans Workstation.

Le paquet fourni packages/candidate.tar.gz a été créé depuis drafts/ pendant la préparation. Le pipeline doit utiliser ce paquet enregistré, sans le reconstruire à partir des brouillons qui auraient changé depuis.

Contrôlez d'abord explicitement le candidat :

python3 tools.py check packages/candidate.tar.gz

Le contrôle affiche sa réussite et l'identifiant du paquet conservé. Simulez maintenant une modification ordinaire après l'empaquetage. > remplace uniquement ce fichier texte du brouillon ; echo affiche le texte entre guillemets :

echo 'UNREVIEWED DRAFT: use the West gate' > drafts/downloads/guide.txt

Confirmez que le brouillon a changé :

cat drafts/downloads/guide.txt

Il affiche UNREVIEWED DRAFT: use the West gate. Cette modification concerne volontairement le brouillon seul. Ne modifiez ni ne reconstruisez le paquet enregistré.

Lancez le pipeline corrigé sur le candidat enregistré :

bash pipeline.sh packages/candidate.tar.gz

Attendez PASS: visitor checks. Frozen package ..., puis Published frozen package ..., avec le même identifiant. L'exécuteur teste une copie conservée et publie exactement ses octets ; il refuse les octets sans contrôle réussi. L'identifiant est un indice complémentaire, pas un remplacement du contrôle du vrai site.

Passez dans Live Website, revenez à l'accueil avec FIELDNOTES et rechargez. Ouvrez Explore the exhibition, Plan your visit et Download visitor guide. La page et le téléchargement indiquent East gate malgré la modification non vérifiée du brouillon. Ouvrez aussi Step-free route et Download access guide ; Garden ramp est conservé. Vérifiez l'illustration et les styles.

Retournez dans Workstation. curl envoie une requête HTTP ; -sS masque la progression mais montre les erreurs de connexion. 127.0.0.1 désigne cet environnement et 8081 est le port du site publié. Exécutez ces requêtes dans Workstation, pas dans le terminal de votre ordinateur :

curl -sS http://127.0.0.1:8081/downloads/guide.txt

Le corps commence par FIELDNOTES Visitor Guide et contient Entrance: East gate. Le site utilise donc le paquet enregistré, pas le brouillon modifié. Si vous voyez le texte du brouillon, examinez l'entrée réellement publiée et relancez le pipeline corrigé sur le candidat fourni inchangé.

Testez enfin un nouveau refus :

bash pipeline.sh packages/missing.tar.gz

Attendez l'échec 404 intentionnel, sans publication. Dans Live Website, rechargez et téléchargez encore le guide ; le candidat accepté reste utilisable. Le pipeline a démontré les deux décisions. Cet exercice protège une publication locale de site statique ; il ne fournit ni contrôle d'accès, ni signatures, ni CI hébergée, ni retour arrière de migration de base de données.

Résumé

Vous avez utilisé l'exécution conditionnelle pour arrêter les mauvaises publications, transmis un même paquet aux deux étapes et publié ses octets testés malgré une modification ultérieure du brouillon. Les parcours général et accessible restent disponibles.