Directrices de compromiso de código usando compromisos tradicionales | de Pragnesh Ghoda | febrero 2023

Exploremos una forma más estructurada de confirmar el historial y cómo facilitar que las personas contribuyan a sus proyectos.Foto de Yancy Min en Unsplash Para hacer coincidir las confirmaciones en todos los repositorios, debemos usar la especificación de confirmaciones convencional. La especificación de confirmaciones convencionales es una convención ligera sobre mensajes de confirmación. Proporciona un conjunto simple de reglas para crear un historial de confirmación explícito; facilitando la escritura de herramientas automatizadas en él. La confirmación convencional facilita que las personas contribuyan a sus proyectos al permitirles explorar un historial de confirmación más estructurado.

Comprometerse

Cada compromiso de código debe contener algunos detalles básicos sobre el compromiso y la descripción del problema. Será más fácil rastrear el ticket desde la confirmación. Será más fácil para los miembros del equipo entender y seguir el patrón si cada miembro del equipo sigue el mismo camino.

solicitud de extracción

Cada PR debe incluir los detalles del boleto y el título del PR. También debe incluir el tipo de ticket para que los miembros del equipo puedan verificar si se trata de una función/mejora o una corrección de errores. En general, el mensaje de confirmación debe estructurarse de la siguiente manera: [optional scope]: [REFERENCE-1234][optional body][optional footer(s)]Los ejemplos prácticos pueden verse así: esfuerzo: [PRJ1-123] Ejecute pruebas en Jenkins cifix (servidor): [PRJ2-1234] Enviar encabezado de CorsEnvíe encabezados de CORS reflejando el encabezado de origen en requestfeat (blog): [PRJ2-1234] Agregar sección de comentarios Confirmar mensaje con alcance, descripción y cambio importante footer:// sin alcance: permitir que el objeto de configuración proporcionado amplíe otras configuraciones CAMBIO IMPORTANTE: la clave «extiende» en el archivo de configuración ahora se usa para ampliar otros archivos de configuración): Compromiso de idioma polaco: agregue un mensaje con texto con varios párrafos y varios pies de página: solución: evitar que las solicitudes se aceleren. Introduzca un ID de solicitud y una referencia a la última solicitud. Rechazo de respuestas distintas a la última solicitud. Elimine los tiempos de espera que se usaron para mitigar el problema de las carreras pero que ahora están en desuso. Revisado por: ZRefs: #123 Una recomendación es usar el tipo de reversión y un pie de página que apunte a los SHA de compromiso revertidos :revert: Nunca volvamos a hablar sobre el incidente de los fideosRefs: 676104e, a215868Use lo siguiente como guía, qué tipos podría usar para tus compromisos.Crédito: autor Los ejemplos del mundo real podrían verse así:Complete los siguientes pasos para poner en marcha el linting de confirmación.

1. Instale el paquete de confirmación previa con brew:

brew install pre-commit // comprobar la versión después de completar la instalación pre-commit –version2. Ejecute el siguiente comando en el directorio de su proyecto: pre-commit install -t commit-msg -t pre-commit -t pre-push – allow-missing-config3. Agregue complementos de confirmación previa a su proyecto. Cree el archivo de configuración .pre-commit-config.yaml en el directorio de su proyecto: default_stages: [commit, push]Repos: – Repo: https://github.com/alessandrojcm/commitlint-pre-commit-hookrev:v2.1.0hooks: – ID: commitlintstages: [commit-msg]Dependencias_adicionales:- «@commitlint/config-conventional»- Conventional-Changelog-Conventionalcommits- Repo: https://github.com/pre-commit/pre-commit-hooksrev:v2.4.0hooks:- ID: check-json- id: check-merge-conflict- id: detect-private-key- id: no-commit-to-branch- repo: https://github.com/jguttman94/pre-commit-gradlerev: v0.3.0hooks:- id: gradle-spotlessargs: [‘-w’, –wrapper]4. Agregue pelusa a su proyecto. Cree el archivo de configuración commitlint.config.js en el directorio de su proyecto:module.exports={extends: [«@commitlint/config-conventional»],// Validar en el problema/número de ticket parserPreset: { parserOpts: { // Estos son ejemplos, agregue posibles prefijos según las necesidades de su proyecto issuePrefixes: [‘ANDR-‘, ‘TEST-‘,’DSC-‘, ‘ABC-‘, ‘CO-‘] }},reglas: {«cuerpo-líder-en blanco»: [ 1, «always» ],»pie de página-principal-en blanco»: [ 1, «always» ],»header-max-length»: [ 2, «always», 72 ],»Caso de alcance»: [ 2, «always», «lower-case» ],»Referencia»: [2,»never»,[ «sentence-case», «start-case», «pascal-case», «upper-case» ]],»sujeto-vacío»: [ 2, «never» ],»Asunto»: [ 2, «never», «.» ],»tipo de caso»: [ 2, «always», «lower-case» ],»tipo-vacío»: [ 2, «never» ],»escriba enumeración»: [2,»always»,[«build»,»chore»,»ci»,»docs»,»feat»,»feature»,»fix»,»perf»,»refactor»,»revert»,»style»,»test»]]}};5. Transfiere los archivos agregados a tu repositorio. La salida debería verse así: > git commit -m ‘fix: [TOL-6911] pelusa de prueba[INFO] Entorno de inicialización para https://github.com/alessandrojcm/commitlint-pre-commit-hook:@commitlint/config-conventional,conventional-changelog-conventionalcommits.Fix End of Files………… . ………………………………AprobadoComprobar JSON…. …….. ……………………………(no hay archivos para escanear)OmitidoComprobar conflictos de fusión.. ….. .. …………………………………PassedDetect PrivateKey…. … .. ………………………………… … PasadoSin compromiso con la sucursal. …………………………………………………. .. ….. ..Aprobado[INFO] Entorno de instalación para https://github.com/alessandrojcm/commitlint-pre-commit-hook.[INFO] Después de la instalación, este entorno se reutiliza.[INFO] Esto puede tardar unos minutos…commitlint………………………………….. …………………………….Passed Hook ID: Commitlint Duración: 0,43 s[branchify-devops-changes fde84e2] Arreglar: [TOL-6911] Pruebe el archivo lint1 modificado, 3 inserciones (+), 3 eliminaciones (-) Listo, ahora ha configurado el linting para los mensajes de confirmación. Además, dado que descubrimos secretos inesperados, deberá configurar la primera línea de base:

1. Instale una herramienta de descubrimiento de secretos (es tan simple como pip install detect-secrets).
2. Ejecute el análisis de detección de secretos > .secrets.baseline en el directorio de su proyecto.
3. Transfiere los archivos agregados a tu repositorio.

Listo, ahora tiene una línea de base para detectar cambios inesperados relacionados con secretos. Pruebe el siguiente comando para validar: git commit –allow-empty -m «» Demos un paso para llegar a una confirmación limpia, al igual que pasamos a un código limpio 😉