Hemos estado usando Azure Devops por un tiempo y tenemos una suite muy grande en un repositorio, con una amplia canalización de Yaml. Tiene todo tipo de trabajos paralelos y tenemos varios agentes alojados disponibles para ejecutar los trabajos en paralelo. Para acelerar las compilaciones, realizo todo tipo de optimizaciones (como el almacenamiento en caché de paquetes nuget). Sin embargo, debido al tamaño de nuestro repositorio, los trabajos de canalización se ejecutan aproximadamente 2 minutos y medio antes incluso de comenzar cualquier tarea, ya que se está ejecutando la tarea de pago para llevar la fuente al agente alojado.
Probablemente agregamos algunos archivos grandes e innecesarios al repositorio al comienzo de nuestro proyecto, y esto probablemente hizo que el repositorio se hinchara un poco. Encontré documentación sobre cómo eliminar archivos grandes del repositorio, pero el documento es bastante vago al respecto. ¿Es esta una forma adecuada de tratar de mejorar el tiempo de pago? Si es así, ¿hay alguien que pueda darme una descripción detallada sobre cómo eliminar archivos no deseados de un repositorio de git y enviarlo a Azure Devops?
Si hay otras cosas que puedo hacer para mejorar la velocidad de pago (aparte de usar agentes privados), estoy abierto a ideas.
danielorn
El comportamiento de pago puede ser personalizado por el checkout palabra clave. En particular, es posible especificar el fetchDepth (el valor predeterminado es sin límite) para realizar una búsqueda superficial, lo que podría mejorar el rendimiento.
Desde los documentos de Azure Devops en Búsqueda poco profunda:
Si su repositorio es grande, esta opción podría hacer que su proceso de compilación sea más eficiente. Su repositorio puede ser grande si ha estado en uso durante mucho tiempo y tiene un historial considerable. También puede ser grande si agregó y luego eliminó archivos grandes.
Ejemplo de canalización de Yaml:
steps:
- checkout: self
clean: true
fetchDepth: 1 # Fetch only one commit
path: PutMyCodeHere
Documentación de desarrollo de Azure para cómo especificar fetchDepth en canalizaciones yaml
-
Eso suena realmente prometedor. Lo probaré a ver que efecto tiene
– Paul Vrugt
10 de abril de 2020 a las 18:48
-
¿Hay alguna desventaja en obtener solo 1 compromiso de git? Para crear una compilación que es.
– Rik de Peuter
29 de enero de 2021 a las 13:20
-
No, siempre y cuando solo esté interactuando con la confirmación actual, que generalmente es el caso en una compilación, no hay inconveniente. Lo que no puede hacer es, por ejemplo, mostrar el historial de git, o verificar o comparar con otras confirmaciones o ramas. (comparando con el compromiso anterior se puede resolver fácilmente especificando
fetchDepth: 2pero para verificar o diferenciar con una confirmación o rama arbitraria, debe clonar todo el repositorio, pero esas no son acciones que normalmente se realizan en una compilación.– danielorn
29 de enero de 2021 a las 16:39
-
@danielorn ¿Sabe si herramientas como GitVersion podrán determinar el número de versión correcto? Fe al construir la rama de desarrollo, ¿probablemente necesite leer etiquetas de la rama maestra/principal?
– huysentruitw
17 de enero de 2022 a las 13:59
-
@Eccentropy, sí, cualquier operación que requiera el historial pasado y no solo la confirmación seleccionada se verá afectada al especificar el
fetchDepth– danielorn
26 de septiembre de 2022 a las 7:06
Agregando a la respuesta aceptada, puede encontrar fetchTags para ayudar mucho si su repositorio tiene muchas etiquetas y no las necesita en su canalización.
Mientras que nuestro paso de pago tomó 6 minutos con solo fetchDepth: 1cuando añadimos fetchTags: false, el paso de clonación se redujo a 30 segundos. Nuestro paso de pago se ve así ahora.
- checkout: self
fetchDepth: 1
fetchTags: false