Guide de la version préliminaire · 0.1.0

Protéger l’historique à envoyer

Approuvez et appliquez la protection d’un clone, examinez ses commits sortants et comprenez la raison exacte d’un blocage.

La référence de l’API est en anglais.

Appliquer la protection au clone prévu

La protection des push utilise un hook Git local installé explicitement. Une analyse échouée ou un contrôle de projet configuré n’installe pas ce hook. Commencez avec un profil d’éditeur connecté, le dépôt source exact autorisé et les analyseurs préparés.

1. Exécutez CodeSecurity: Protect Pushes… dans VS Code. La palette demande un dépôt ; le menu d’un dépôt Source Control utilise le clone sélectionné.
2. Vérifiez l’identité du dépôt. Résolvez une sélection périmée ou ambiguë avant de continuer.
3. Demandez l’accès au dépôt, puis approuvez cette génération exacte d’éditeur dans le navigateur associé du propriétaire. L’appartenance IDE ordinaire ne donne pas ce droit.
4. Choisissez l’état demandé On, puis explicitement Apply dans VS Code.
5. Lisez l’état de l’hôte et résolvez tout conflit de hooks avant de vous fier à la protection.

Le réglage Web enregistre l’état demandé. Change pending · Apply in VS Code indique que l’hôte ne l’a pas appliqué. Cela vaut aussi pour Off : un hook On déjà appliqué peut continuer à bloquer tant que le changement n’est pas appliqué. On · last verified et Off · last applied décrivent la dernière observation.

Le hook invoque un assistant hôte fourni séparément. Il fonctionne donc avec l’éditeur fermé lorsque le backend requis reste disponible. L’installation préserve les autres hooks et la configuration locale de leur chemin ; un conflit impossible à composer sans risque est refusé. Réglages Git globaux et remotes restent inchangés.

Examiner les commits sortants avant le push

Exécutez CodeSecurity: Check Outgoing Commits… depuis la palette ou le menu Source Control du dépôt prévu. Choisissez destination configurée, branche ou tag local et référence distante explicite. Examinez ce périmètre avant soumission des instantanés et analyses. Cette commande vérifie ; elle ne pousse rien.

La vérification lie dépôt canonique, couples ref/objet sortants, arbres sources immuables, couverture autorisée, politique actuelle et éléments d’analyse. Une analyse de workspace, fichier ou dossier, ou la dernière analyse choisie dans l’interface, ne remplace pas cet historique commité.

Par exemple, un secret ajouté dans un commit sortant puis supprimé dans le suivant voyage encore dans le premier. Une tête propre ne l’efface pas. Examinez l’arbre historique en échec au lieu de réanalyser seulement les derniers fichiers de travail.

Chaque dépôt possède un résultat indépendant. Un contenu immuable inchangé peut réutiliser des éléments applicables ; des refs, politiques, décisions sur les constats ou identités d’analyseurs/données modifiées peuvent invalider l’approbation. Vérifier le catalogue organisé n’installe pas de nouvelles données. La disponibilité actuelle détermine toujours l’utilisabilité des éléments.

Lire l’issue du plan exact

Un push contenant des arbres sources exige des éléments terminés, applicables et réussis. Une vérification absente, échouée, périmée, partielle, annulée ou indisponible bloque l’envoi. Désactiver le contrôle ne produit pas une réussite, et changer des décisions ne comble pas la couverture.

Un plan de suppression seule ou sans effet n’a aucun arbre source sortant à analyser. Il peut terminer sans exécuter les analyseurs, mais l’approbation du dépôt et la politique actuelle restent exigées. Lisez le plan réel ; une liste vide ne prouve pas l’absence d’arbre.

Annuler une vérification arrête son job annulable actuel et conserve les résultats antérieurs. Une vérification annulée conservée peut proposer Start new check, avec périmètre et anciennes identités de jobs et analyses. Accepter revérifie l’état actuel et peut réutiliser les éléments terminés applicables. Cela ne rebaptise pas la vérification annulée en réussite.

Diagnostiquer un push bloqué

Git ou GitLens peuvent afficher un conseil générique de pull. Ouvrez Show Command Output dans VS Code ou Open Output Channel dans GitLens et lisez le résultat réel. Si Lomo blocked this push apparaît, revenez à la protection et à la vérification sortante de ce clone.

Utilisez Review blocking findings après une analyse sortante terminée mais échouée. L’action ouvre l’analyse exacte de l’arbre commité ; choisissez la bonne si plusieurs arbres échouent. Des éléments historiques ne peuvent ouvrir le fichier actuel comme s’il était l’arbre contrôlé. Open protection settings ouvre le dossier du dépôt sans modifier contrôle ou permission.

Une branche non publiée, un remote mal configuré ou Nothing to push peut arrêter le client avant le hook. Ces messages ne prouvent aucune autorisation CodeSecurity. Confirmez branche et destination Git ordinaires en plus du résultat de sécurité.

Reconnaître les limites de couverture

La couverture concerne les fichiers ordinaires des arbres de commits nouvellement sortants. Messages de commit, messages de tag et métadonnées Git hors fichiers ne sont pas des entrées d’analyse. Liens symboliques, sous-modules, dépôts superficiels, stockages d’objets alternatifs non pris en charge et couverture invérifiable sont refusés.

Une ref distante existante exige son ancien commit en local. Une nouvelle branche n’a pas d’ancienne base : tout l’historique accessible depuis sa tête compte pour la limite, même si une autre branche distante en contient une partie. La vérification ne récupère pas silencieusement les objets manquants et ne tronque pas l’historique.

Un refus de limite n’autorise aucun push. Réduisez les refs si cela résout leur limite, ou organisez un parcours distinct approuvé de revue et d’application pour les arbres ou historiques non pris en charge. Une petite analyse de workspace ne fournit pas les éléments manquants.

Désactiver ou retirer la protection

Passer à Off exige l’avertissement et l’application explicite sur l’hôte. Annuler laisse l’état inchangé. Après application de Off, l’assistant ne lit pas les sources, n’exige pas d’API en ligne et n’impose pas les limites de sources/refs propres à On. Enregistrement et configuration du hook restent disponibles pour réactivation explicite.

Le retrait est une autre action. Dans le profil propriétaire exact, choisissez Protect Pushes… > Remove push protection from this clone… et confirmez le dépôt. Le retrait vise uniquement le hook Lomo inchangé, l’enregistrement de protection et les droits et liaisons propres au dépôt. Projets, analyses, constats, instantanés conservés, association générale, remotes et hooks d’autres outils restent intacts.

Un projet encore utilisé par la protection ou sa source d’instantanés Git ne peut être supprimé, même avec Off. Retirez d’abord l’enregistrement si vous souhaitez ensuite supprimer séparément le projet.

Si le retrait local réussit mais que le nettoyage serveur est indisponible, réessayez depuis le même profil au retour du service. Les fichiers de hook modifiés ou inconnus sont préservés. Après révocation et réinscription d’un éditeur, faites approuver la nouvelle génération et appliquez explicitement à nouveau ; l’ancien droit de dépôt n’est pas hérité.

Tester sans publier les sources

Pour une vérification manuelle délibérée, utilisez un dépôt jetable et un remote bare local exact. Employez des constats synthétiques et vérifiez les refs distantes avant et après de vrais push Git ordinaires. Un blocage doit les laisser inchangées ; un push permis ne modifie que les refs prévues. Incluez un historique ancien problématique suivi d’une tête propre pour qu’un contrôle de la seule tête ne paraisse pas suffisant.

Le propriétaire peut contourner un hook local ou employer un autre clone. Gardez des contrôles distants adaptés si l’application doit être incontournable. Une vérification manuelle réussie couvre les cas exercés, pas toutes les plateformes, refs ou récupérations.

Consultez décisions de contrôle, revue des constats et API de protection Git pour les fonctions associées.