Guide de la version préliminaire · 0.1.0
Lire et configurer le contrôle d’analyse d’un projet
Distinguez l’analyse terminée de sa décision de politique, puis ajustez les seuils du projet prévu sans changer l’accès aux sources ni la protection des push.
La référence de l’API est en anglais.
Lire la couverture avant la décision du contrôle
L’analyse décrit ce qui s’est passé pendant l’exécution. Son contrôle indique si les éléments applicables satisfont la politique du projet. Lisez les deux dans le résumé Findings.
| Résultat affiché | Conséquence pour la suite |
|---|---|
| Analyse complète et contrôle réussi | L’analyse respecte la politique active pour son périmètre et ses éléments enregistrés. Vérifiez qu’il s’agit des sources et du périmètre prévus. |
| Analyse complète et contrôle échoué | L’analyse est terminée, mais une ou plusieurs conditions de politique ont échoué. Examinez les raisons et les constats concernés. |
| Analyse partielle, échouée ou annulée | Des constats utiles peuvent subsister, mais l’analyse manquante ne constitue pas une preuve complète acceptée. Résolvez la couverture puis relancez. |
| Contrôle non configuré ou désactivé | Aucune politique active du projet n’établit de réussite. Cela ne peut autoriser un push protégé. |
Une liste vide ne suffit à établir aucun de ces résultats. Des filtres peuvent masquer des constats, un analyseur peut avoir échoué ou l’analyse ne couvrir qu’un fichier. Le résumé et les raisons du contrôle préservent ces distinctions.
Fin de l’analyse, décision de contrôle et protection installée sont trois états distincts. Examinez les constats pour comprendre l’échec du contrôle.
Ouvrir l’image complèteConfigurer uniquement le projet prévu
Ouvrez Projects, choisissez le projet et trouvez Repository scan gate. Vérifiez son nom avant modification. Le formulaire propose quatre commandes :
- Evaluate this project’s gate active ou désactive l’évaluation de politique de ce projet.
- Maximum critical findings fixe le nombre de constats critiques comptabilisés permis.
- Maximum high findings fixe le nombre de constats de gravité haute comptabilisés permis.
- Block secrets in this project ajoute la condition relative aux secrets signalés.
Un maximum de 0 ne permet aucun constat comptabilisé à cette gravité. 2 en permet deux et échoue au-delà. -1 ne fixe aucune limite pour cette gravité. Le formulaire accepte des seuils jusqu’à 999.
Choisissez les valeurs de la politique de revue, puis Save project gate. L’enregistrement recalcule les contrôles des analyses existantes de ce projet. Il ne modifie aucun autre projet, n’analyse pas les sources, n’autorise aucun répertoire, ne prépare aucune donnée et n’installe aucun hook Git.
La condition de secrets porte sur les constats reconnus par les correspondances d’analyseur, règle et message du contrôle. Elle ne prétend pas détecter tous les secrets possibles. Examinez les rapports sous-jacents lorsqu’elle échoue.
Séparer brouillons et politique enregistrée
Reset draft restaure les dernières valeurs enregistrées chargées dans ce formulaire. Reload policy lit la politique actuelle du serveur en conservant les modifications non enregistrées pour comparaison et revue. Changer de projet conserve chaque formulaire dans son propre périmètre.
Si l’enregistrement signale un conflit ou si la politique actuelle ne peut être lue, rechargez et réconciliez avant de réenregistrer. Une lecture échouée n’est pas une politique vide. Si l’issue d’un enregistrement est incertaine, examinez l’état sauvegardé avant une nouvelle modification.
Comprendre ce qui est compté
Le contrôle compte les constats actifs qui ne sont ni supprimés du comptage ni exemptés. Open et Needs review restent comptables selon la politique. Non-blocking for gate et Accepted risk conservent un constat actif exempté. Ignore, False positive et Fixed l’excluent des comptes actifs.
Ce sont des décisions motivées, décrites dans le guide du cycle de vie. Marquer Fixed ne vérifie pas une correction. Une nouvelle analyse fournit les éléments relatifs au code modifié.
Modifier les décisions peut permettre à une analyse terminée de satisfaire sa politique. Cela ne comble pas l’analyse manquante d’un résultat partiel ou échoué. La réponse ou la confiance d’Advisor ne constitue pas non plus une décision du contrôle.
Relier le contrôle à la protection des push
Un contrôle de projet ne bloque pas Git à lui seul. La protection des push exige une approbation distincte propre au clone et l’application explicite du hook local dans VS Code.
Pour un push envoyant des arbres de sources, la protection exige des éléments actuels, complets et acceptés pour l’historique sortant exact. Une analyse de fichier réussie, une ancienne analyse du workspace ou une autre référence ne les remplace pas. Politique, décisions, éléments d’analyse ou références sortantes modifiés peuvent nécessiter une nouvelle vérification.
Un plan sortant limité à une suppression ou sans effet ne contient aucun arbre à analyser, mais l’approbation du dépôt et la politique actuelle s’appliquent encore. Le parcours de protection distingue ce cas d’un push contenant des sources.
Consultez les opérations de contrôle pour la politique de projet, les opérations de configuration pour leurs commandes d’exécution distinctes, et l’architecture d’analyse pour le chemin des éléments vers la décision.