Solución:
Esto depende de sus necesidades reales.
Siempre que pueda ejecutar su canalización completa en un solo nodo, envolvería el stages en un node para que la canalización no sea bloqueada por ejecutores ocupados.
Tan pronto como use el parallel paso, entonces realmente no tienes otra opción además de tener stage alrededor node asignaciones.
No hay (al menos para mí) problemas al mezclar eso, es decir, tener las primeras 2-3 etapas ejecutadas en el mismo nodo y luego una etapa que se ejecuta en múltiples nodos dentro parallel.
Con node { stage { ... } } cada etapa compartirá la misma carpeta de trabajo y todos los archivos de la etapa anterior estarán allí para la siguiente etapa.
Con stage { node { ... } } necesitas stash/unstash archivos entre cada etapa. Si tiene un repositorio grande, y especialmente si tiene una carpeta grande de dependencias como node_modules, esto repite stash/unstash podría terminar siendo significativo, o incluso mayoritario, o su tiempo de construcción.
En mi opinión, generalmente comenzaría con la primera sintaxis, node { stage { ... } } como se prefiera. Si tiene etapas de construcción individuales que requieren tiempo y pueden beneficiarse del paralelismo, entonces cambie a stage { node { ... } } podría ser mejor, siempre y cuando el tiempo ganado en la paralelización no se pierda en el almacenamiento.
Actualizar:
Probé el efecto exacto de intercambiar anidación en una de nuestras compilaciones. con un montón de etapas dentro de un nodo, el tiempo total de construcción es de poco más de un minuto. Con un nodo dentro de cada etapa, el tiempo total de construcción es de casi cinco minutos. Gran diferencia.
