Guía de la versión preliminar · 0.1.0
Leer y configurar el control de análisis de un proyecto
Distingue un análisis terminado de su decisión de política y ajusta los umbrales del proyecto previsto sin cambiar acceso al código ni protección de push.
La referencia de la API está en inglés.
Lee la cobertura antes de la decisión del control
El análisis informa de lo sucedido durante la ejecución. Su control indica si la evidencia aplicable cumple la política del proyecto. Lee ambos en el resumen de Findings.
| Resultado visible | Consecuencia para el siguiente paso |
|---|---|
| Análisis completo y control superado | Cumple la política activa para el alcance y la evidencia registrados. Comprueba que sean el código y el alcance previstos. |
| Análisis completo y control fallido | Terminó el análisis, pero falló alguna condición de política. Revisa las razones y los hallazgos pertinentes. |
| Análisis parcial, fallido o cancelado | Puede conservar hallazgos útiles, pero la ausencia de análisis no se convierte en evidencia completa aprobada. Resuelve la cobertura y vuelve a analizar. |
| Control sin configurar o deshabilitado | Ninguna política activa del proyecto establece una aprobación. No puede autorizar un push protegido. |
Una lista vacía de hallazgos no basta para establecer ninguno de estos resultados. Puede haber filtros, un analizador fallido o un alcance de un solo archivo. El resumen y las razones del control conservan esas diferencias.
La finalización del análisis, el resultado del control y la protección de push instalada son estados independientes. Inspecciona los hallazgos para entender un control fallido.
Abrir la imagen completaConfigura únicamente el proyecto previsto
Abre Projects, elige el proyecto y busca Repository scan gate. Comprueba su nombre antes de editar. El formulario tiene cuatro controles:
- Evaluate this project’s gate habilita o deshabilita la evaluación de este proyecto.
- Maximum critical findings fija el número permitido de informes críticos contabilizados.
- Maximum high findings fija el número permitido de informes de gravedad alta contabilizados.
- Block secrets in this project añade la condición de informes de secretos.
Un máximo de 0 no permite hallazgos contabilizados de esa gravedad. Un máximo de 2 permite dos y falla al superarlos. -1 deja esa gravedad sin límite. El formulario acepta umbrales hasta 999.
Elige valores acordes con la política de revisión y pulsa Save project gate. El guardado recalcula los controles de los análisis existentes de ese proyecto. No cambia otros proyectos, analiza código, autoriza directorios, prepara datos ni instala un hook Git.
La condición de secretos opera sobre informes reconocidos por la coincidencia de analizador, regla y mensaje del control. No afirma haber detectado todos los secretos posibles. Inspecciona los informes subyacentes si falla esa condición.
Distingue borradores y política guardada
Reset draft restaura los últimos valores guardados cargados en este formulario. Reload policy lee la política actual del servidor y conserva los cambios sin guardar para compararlos y revisarlos. Al cambiar de proyecto, cada formulario sigue vinculado a su proyecto.
Si el guardado indica conflicto o no puede leerse la política actual, recarga y contrasta antes de guardar otra vez. Una lectura fallida no es una política vacía. Si el resultado del guardado es incierto, inspecciona lo guardado antes de enviar otro cambio.
Entiende qué se contabiliza
El control cuenta hallazgos activos no suprimidos ni exentos. Open y Needs review siguen sujetos al cómputo de la política. Non-blocking for gate y Accepted risk conservan un informe activo exento del control. Ignore, False positive y Fixed lo excluyen de los recuentos activos.
Son decisiones razonadas descritas en la guía del ciclo de vida. Marcar Fixed no verifica una reparación. Un nuevo análisis aporta evidencia sobre el código cambiado.
Cambiar decisiones puede hacer que un análisis terminado cumpla la política. No puede completar evidencia ausente en un análisis parcial o fallido. El control tampoco trata una respuesta o confianza de Advisor como decisión de política.
Relaciona el control con la protección de push
El control del proyecto no bloquea Git por sí solo. La protección de push necesita aprobación separada para el clon y aplicación explícita del hook local en VS Code.
Para un push que envía árboles de código, la protección comprueba evidencia actual, completa y aprobada para el historial saliente exacto. No la sustituye un análisis de archivo aprobado, un análisis anterior del espacio de trabajo o una referencia diferente. Cambios de política, decisiones, evidencia o referencias salientes pueden exigir otra comprobación.
Un plan saliente solo de eliminación o sin cambios no contiene árbol que analizar, pero siguen aplicándose aprobación del repositorio y política actual. El flujo de protección distingue este caso del push que lleva código.
Consulta las operaciones de controles para solicitudes de política, las operaciones de configuración para controles de ejecución separados y la arquitectura de análisis para el recorrido de la evidencia hasta la decisión.