Automatizando los cambios de Repo en Hudson

Estoy armando una configuration de Hudson y nuestro process de construcción ha generado un obstáculo. Hace time que somos una tienda web, pero ahora estamos haciendo más proyectos Java. Cada 2 semanas creamos una label de la carpeta raíz justo después de lanzar la label anterior a la producción. La nueva label se testing durante 2 semanas (y los cambios críticos se combinan) mientras el desarrollo continúa en el tronco. La mayoría de las confirmaciones no están relacionadas con Java, por lo que no es necesario crear el proyecto Java cada vez, solo se detectan cambios en Java.

Lo que quiero hacer es configurar hudson para sondear la label de testing de los cambios y luego comstackr e implementar en nuestro server de testing. Sin embargo, dado que lanzamos cada 2 semanas, la URL del repository de testing cambiará junto con ella. Obviamente, podría actualizar manualmente la URL de repos, pero quiero automatizar esto para evitar errores humanos. ¿Hay alguna forma de crear una especie de url svn symlink que pudiéramos tener un cambio de guión para apuntar a la nueva label cuando lancemos? ¿Hay algún mecanismo de scripting que pueda usar para ejecutar y actualizar automáticamente el repository de hudson desde la CLI? ¿Alguna otra idea para arreglar esto?

¿Qué tal si reutilizas la misma label cada dos semanas?

Siguiendo la descripción del process que usa. Cuando crea un lanzamiento, copy el tronco en una label nueva y lo testing hasta que sea lo suficientemente bueno (alnetworkingedor de dos semanas). Luego de lanzar esta label

Cambios propuestos: después de lanzar una versión. Copia el tronco a la twig 'ReleaseCandidate'. Lo testing allí hasta que sea bueno para liberarlo. Al liberar, usted crea específicamente la label de liberación (por ejemplo, Rel_3_5_2) y copy el Candidato de versión en la label de publicación. Ahora puede reutilizar la twig ReleaseCandidate y copyr el tronco allí.

Su Hudson siempre se ejecuta contra ReleaseCandidate y trunk


Otra solución sería pasar la URL al trabajo utilizando un enlace de confirmación de publicación. Este gancho primero tendrá que averiguar qué label acaba de cambiar y desencadenar el trabajo con esta URL.