samykabu/github-wiki-publish

Publication vers Wiki GitHub

Publier le matériel demandé dans le Wiki existant du dépôt. Garder la génération de contenu séparée de la publication : utiliser les pages, rapports et ressources fournis, en adaptant les liens et la navigation si nécessaire. Suivre les règles du projet cible sans importer de conventions d'un autre projet.

Établir la destination et le périmètre

• Résoudre l'hôte GitHub, le dépôt, l'URL du Wiki, les fichiers sources et les noms de pages prévus à partir de la demande et du contexte du dépôt. Ne demander que les choix non résolus qui modifient substantiellement la publication.
• Distinguer la préparation de la publication. Une demande explicite de publication autorise la mise à jour nommée du Wiki ; ne pas redemander la même action. Une demande de brouillon ou d'évaluation seule n'autorise pas un envoi (push).
• Découvrir d'abord les capacités du connecteur pertinent. S'il ne peut pas gérer correctement le contenu et les ressources du Wiki, utiliser le dépôt Git séparé du Wiki. Expliquer brièvement la solution de repli. Les API de contenu de dépôt ordinaires ne traitent pas le dépôt Wiki.
• Vérifier l'accès en utilisant la connexion authentifiée existante ou les identifiants Git. Ne jamais intégrer d'identifiants dans les URL, les pages ou les preuves conservées. Une erreur 404 non authentifiée ne prouve pas qu'un Wiki privé est absent.
• Si aucun dépôt Git Wiki n'existe, vérifier si le Wiki est désactivé ou si sa première page doit être créée via GitHub. Ne pas activer les fonctionnalités du dépôt ni modifier l'accès comme effet de bord. Utiliser une création de première page autorisée si possible ; sinon, signaler le prérequis manquant spécifique.

Préparer une mise à jour limitée

Pour une publication Git, lire la procédure Git. Utiliser un clone temporaire frais, découvrir sa branche par défaut réelle et lire les pages de destination existantes, la page d'accueil (Home) et la barre latérale avant d'écrire.

• Mapper chaque fichier source vers une page ou une ressource de destination. Préserver les pages non liées, les sections rédigées manuellement et la navigation. Un fichier source absent n'est pas une instruction de suppression. Remplacer une page entière uniquement lorsqu'elle appartient à la mise à jour demandée ; utiliser une modification ciblée pour le contenu partagé (Home/barre latérale). Conserver les liens existants et éviter les entrées de navigation en double lors d'exécutions répétées.
• Lire et écrire le texte explicitement en UTF-8. Copier les ressources binaires octet par octet. Ne pas réparer silencieusement des faits sources ni actualiser un rapport à partir d'un ensemble de données différent. Préserver sa date réelle, sa provenance et ses limitations ; utiliser le générateur amont approprié uniquement si la régénération fait partie du périmètre.
• Réécrire les liens pour la destination réelle du Wiki. Les liens relatifs au dépôt peuvent être cassés après le déplacement d'une page. Copier les ressources référencées ou créer un lien vers une révision accessible du dépôt ; ne pas laisser de chemins locaux, de liens vers des branches non publiées ou des ressources externes inaccessibles.
• Le Wiki affiche le nom du fichier de la page comme titre ; donc une page qui commence par son propre H1 l'affiche deux fois. Supprimer ce H1 et nommer la page d'après lui, en ne gardant un H1 que lorsqu'il diffère intentionnellement du nom de la page (comme pour Home) ; mettre à jour la navigation avec les noms dérivés. Home est servi à /wiki, donc ses liens relatifs résolvent en dehors du Wiki : utiliser des URL absolues du Wiki pour les images, les liens de page et la barre latérale.
• Utiliser des images en ligne prises en charge avec un texte alternatif pertinent. Pour un rapport HTML ou un diagramme animé/interactif, fournir un aperçu statique utile et des liens vers l'artefact original lorsque le Wiki ne peut pas le rendre. Ne pas décrire un fichier HTML téléchargeable comme une application servie à l'intérieur du Wiki. Suivre les outils de diagramme spécifiques au projet lors de la génération de nouveaux graphiques dans le périmètre ; aucun générateur particulier n'est requis par cette compétence.
• Vérifier les liens locaux et les ressources, le texte non ASCII représentatif, et les chemins modifiés exacts. Inspecter le diff final pour détecter les suppressions involontaires, le contenu écrasé, les identifiants et les débris générés. Conserver les clones temporaires et les preuves locales hors du dépôt applicatif, sauf si l'utilisateur ou le projet exige que les sources soient conservées là.

Publier et vérifier

Appliquer la publication uniquement dans le cadre de l'autorisation existante de l'utilisateur. Une mise à jour du Wiki n'autorise pas l'envoi d'une branche applicative, la modification des problèmes, le déploiement d'un site, la planification d'une synchronisation ou l'installation d'une CI.

• Ne commiter que les chemins Wiki prévus, puis récupérer et réconcilier les modifications simultanées comme décrit dans la procédure Git. Envoyer normalement vers la branche par défaut découverte du Wiki. Ne jamais forcer l'envoi pour contourner un autre rédacteur.
• En cas de rejet, récupérer et inspecter une fois. Intégrer les modifications compatibles et revérifier le diff complet. Si le même conflit se reproduit, que l'intention ne peut être résolue ou que l'accès échoue, arrêter les tentatives et conserver le clone récupérable avec un blocage précis. Ne pas le supprimer en cas d'échec.
• Vérifier le commit publié par rapport au dépôt distant en ligne. Un arbre de travail propre seul ne prouve pas que les commits locaux ont été envoyés.
• Inspecter la page réellement servie via un navigateur authentifié lorsque disponible : texte de la page, Unicode représentatif, navigation, liens, chargement des images et lisibilité. Pour les graphiques, comparer le résultat rendu avec les faits sources. Vérifier une image en taille réelle lorsque son aperçu en ligne obscurcit les étiquettes. Corriger les défauts observés dans le périmètre et revérifier le contenu concerné.
• Si la vérification rendue authentifiée n'est pas disponible, signaler la publication et la vérification à distance séparément du contrôle navigateur non exécuté. Ne pas revendiquer un passage rendu à partir de fichiers locaux, d'une réponse HTTP ou d'un envoi réussi.

Signaler l'URL de la page, la révision publiée, les modifications matérielles, les contrôles effectués et toute limitation non résolue. Conserver les chemins de récupération lorsque le travail reste non publié. Ne pas ajouter de nouvelle porte d'approbation, de schéma de contenu, de cycle de vie de projet ou de régime de test.