2011-07-24 12 views
9

Nuestro equipo usa jenkins y git. Estamos buscando implementar la característica avanzada del plugin git que permite compilaciones previas antes de enviar commits al repositorio bendecido. Ver https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin#GitPlugin-AdvancedFeaturesgit jenkins función avanzada

Sin embargo, tengo problemas para comprender todo el proceso.

He aquí un extracto:

Configurar el proyecto Jenkins, y deje el campo 'rama' en el espacio en blanco Git SMC. Esto hará que Jenkins considere cualquier cambio en cualquier rama para la construcción.

A continuación, elija un nombre de rama particular como destino de integración en la sección 'Avanzado' (por ejemplo, 'maestro' o 'estable') y seleccione 'Fusionar antes de compilación'.

Seleccione 'Volver a colocar las etiquetas GIT en el repositorio de origen' de las acciones posteriores a la compilación (esto es necesario para actualizar su repositorio centralizado de git con los resultados de la compilación).

Ahora, los desarrolladores nunca deben comprometerse directamente con su rama de integración (el 'maestro' o 'estable'). En su lugar, deben usar ramas de características o crear nuevas ramas remotas en la confirmación (por ejemplo, "origen de git push HEAD: refs/heads/myNewFeature"). También puede configurar su repositorio de GIT para que solo acepte confirmaciones en la rama de integración de Jenkins.

Ya ha terminado. Los commits ahora se deben fusionar automáticamente con la rama de integración (fallarán si no se combinan limpiamente) y se generarán. Si la compilación tiene éxito, el resultado de la fusión se retrotraerá al repositorio remoto de git.

Lo que entiendo es,

  1. los desarrolladores a crear sucursales remotas, de la que Jenkins se tire de
  2. Jenkins fusionar la rama con su rama integración y construir
  3. Si la generación tiene éxito, la fusión será empujada a blessed-repo/master.

La pregunta es si la compilación falla, ¿cuál es el estado de la rama de integración? Solo supondría que de alguna manera se revierte a la confirmación antes de la fusión. De lo contrario, la rama de integración mantendría la fusión que rompió la construcción, por lo que es imposible fusionar y construir otras ramas.

¿Es esto cierto? Lamentablemente, no está claro desde la wiki.

Además, ¿alguien sabe de un ejemplo que pueda ver?

+0

Tengo una pregunta similar aquí, es decir [cómo usar la fusión de ramas previa a la compilación de Jenkins solo para las ramas que realmente deseo fusionar] (http://stackoverflow.com/questions/22732145/how-to-use-jenkins -pre-build-branch-merging-only-for-branches-i-want-to-merge) en lugar de todos los – nh2

+0

Consulte este artículo: http: //www.yegor256.com/2014/07/24/rultor-automated-merging.html – yegor256

Respuesta

2

Por lo que puedo ver de la GitSCM.checkout method, la fusión se inicia por primera vez por un check out, y, si falla la fusión, restaurar la rama candidato con otro de pago:

// checkout origin/blah 
ObjectId target = git.revParse(mergeOptions.getRemoteBranchName()); 

git.checkoutBranch(paramLocalBranch, target.name()); 

try { 
    git.merge(revToBuild.getSha1().name()); 
} catch (Exception ex) { 
    // We still need to tag something to prevent 
    // repetitive builds from happening - tag the 
    // candidate 
    // branch. 
    git.checkoutBranch(paramLocalBranch, revToBuild.getSha1().name()); 
    [... tag applied ...] 
    buildData.saveBuild(new Build(revToBuild, buildNumber, Result.FAILURE)); 
    throw new AbortException("Branch not suitable for integration as it does not merge cleanly"); 
} 

Así que no creo que una la fusión fallida tiene consecuencias en las compilaciones posteriores.