Historia de sangre y lágrimas
Recientemente, encontré un problema muy extraño al usar Jenkins para extraer el proyecto Git para compilar el código : la versión del código de descarga GitPlugin de Jenkins es incorrecta (commitId es incorrecto). Dado que el producto compilado de la implementación en línea y la implementación fuera de línea son la misma versión, la versión del código finalmente lanzada al entorno de producción es incorrecta. Este problema finalmente se descubrió durante la fase de verificación en línea. Mirando hacia atrás en todo el proceso de construcción del trabajo, la consola no reportó un error y el paquete en línea se compiló correctamente. Entonces, ¿qué salió mal?
Posicionamiento inicial
Al principio, sospeché que era un problema residual del proyecto local de Git , así que intenté eliminar el directorio WORKSPACE en el nodo de la máquina donde se estaba ejecutando el trabajo correspondiente de jenkins para asegurarme de que se pueda extraer el último código la próxima vez que se active la compilación de Jenkins.
Método de eliminación:
1. Inicie sesión en la máquina donde se está ejecutando el trabajo (verifique el nodo donde se está ejecutando el trabajo en la consola, hay una impresión en la primera línea ).
2. Marque $ WORKSPACE (verifique en la consola de trabajo; si no puede encontrarlo, agregue una línea de echo $ WORKSPACE al ejecutor de shell y vuelva a ejecutar el trabajo)
3. Elimine la información del ESPACIO DE TRABAJO correspondiente. Por favor, opere con precaución , primero vea si el valor de WORKSPACE es correcto (echo $ WORKSPACE), no se equivoque y elimine el directorio raíz. ! ! .
[-d "$ ESPACIO DE TRABAJO"] && rm -rf $ {ESPACIO DE TRABAJO}
4. Vuelva a activar el trabajo después de la eliminación
Después de hacer esto, el producto compilado empaquetado final todavía tiene la versión incorrecta.
Dado que no es un problema de almacenamiento en caché de código local, ¿es posible que la versión sea incorrecta cuando GIt extrae el código?
Segunda resolución de problemas
Abra los detalles de configuración del trabajo en Jenkins, solo completé " * / qa " en BranchSpecifier , mi expectativa es coincidir con la rama qa en el proyecto específico de git (URL del repositorio) .
Luego, mire el registro de la compilación anterior que tuvo un problema (abra la página de detalles del trabajo de la compilación actual) y haga clic en Git Build Data (a la izquierda):
Aquí se muestran dos ramas remotas. Solo configuré una rama qa en GitPlugin . Solo debería haber una rama llamada qa que se está descargando. ¿Cómo es que hay dos ramas?
Comencé a sospechar que podría ser un problema de coincidencia de reglas con BranchName en la configuración de Git Plugin, lo que provocó que dos ramas coincidieran aquí (una se llama qa y la otra se llama origin / qa).
Abra la configuración del trabajo correspondiente en Jenkins nuevamente, vemos que "* / qa" se completa en BranchSpecifier, * es un comodín, habrá exactamente dos ramas en este proyecto, como se muestra en la figura anterior (origen / qa Y qa), ¿coincide exactamente con * / qa?
Pensándolo de esta manera, tenía sentido, así que hice clic en el signo de interrogación en el lado derecho de la columna de Especificador de ramas para ver la ayuda, y pude ver la información de ayuda.
Análisis detallado
// La siguiente oración significa: si no completa el especificador de rama (déjelo en blanco o escriba alguno), entonces se emparejará cualquier rama, es decir, qué rama no puede usar en el proyecto. Por lo general, esto no se recomienda.
Especifique las ramas si desea realizar un seguimiento de una rama específica en un repositorio. Si se deja en blanco, se examinarán todas las ramas para detectar cambios y se construirán.
// La siguiente oración significa: La forma más segura es usar la sintaxis de refs / heads / <branchName>
La forma más segura es usar la sintaxis refs / heads / <branchName>. De esta forma, la rama esperada es inequívoca.
// Si su rama contiene '/' (por ejemplo, origin / qa ), es mejor usar la sintaxis mencionada anteriormente: refs / heads / <branchName>
Si el nombre de su sucursal tiene una /, asegúrese de utilizar la referencia completa anterior. Cuando no se le presenta una ruta completa, el complemento solo usará la parte de la cadena a la derecha de la última barra. Lo que significa que foo / bar coincidirá con la barra.
Si usa un especificador de rama comodín, con una barra (por ejemplo, release /), deberá especificar el repositorio de origen en los nombres de las ramas para asegurarse de que se recojan los cambios. Por ejemplo, origen / lanzamiento /
Posibles opciones:
<branchName> // branchName es solo un comodín. Por ejemplo, reale puede coincidir con la rama de lanzamiento, o puede coincidir con el origen / lanzamiento. Por lo general, no escriba esto (de lo contrario, pisará el mismo pozo que yo)
// Debido a la ambigüedad al especificar <branchName>, se recomienda usar refs / heads / <branchName> para especificar claramente una rama remota específica.
Rastrea / comprueba la rama especificada. Si es ambiguo, se toma el primer resultado, que no es necesariamente el esperado. Es mejor utilizar refs / heads / <branchName>.
Por ejemplo, master, feature1, ...
refs / heads / <branchName>
Rastrea / verifica la rama especificada. // verifica una rama remota
Por ejemplo, refs / heads / master, refs / heads / feature1 / master, ...
<remoteRepoName> / <branchName>
Rastrea / comprueba la rama especificada. Si es ambiguo, se toma el primer resultado, que no es necesariamente el esperado.
Es mejor usar refs / heads / <branchName>. // Este método de especificar ramas remotas específicas puede ser ambiguo. Se recomienda usar refs / heads / <branchName>
Por ejemplo, origen / maestro
remotes / <remoteRepoName> / <branchName>
Rastrea / comprueba la rama especificada. // Esta forma de especificar también es más precisa.
Por ejemplo, mandos a distancia / origen / maestro
refs / remotes / <remoteRepoName> / <branchName>
Rastrea / comprueba la rama especificada.
Por ejemplo, refs / remotes / origin / master // etiqueta especificada por checkout, de hecho, tagName aquí no se considerará una etiqueta, por lo que no se recomienda escribirla.
<tagName>
Esto no funciona porque la etiqueta no se reconocerá como etiqueta.
Use refs / tags / <tagName> en su lugar ... // verifique la etiqueta especificada, esta es la sintaxis correcta.
Por ejemplo, git-2.3.0
refs / tags / <tagName>
Rastrea / revisa la etiqueta especificada.
Por ejemplo, refs / tags / git-2.3.0
<commitId>
Comprueba la confirmación especificada. // checkout 指定 的 commitid
Por ejemplo, 5062ac843f2b947733e6a3b105977056821bd352, 5062ac84, ...
$ {ENV_VARIABLE}
También es posible utilizar variables de entorno. En este caso, las variables se evalúan y el resultado se utiliza como se describe anteriormente.
Por ejemplo, $ {TREEISH}, refs / tags / $ {TAGNAME}, ...
<Tarjetas salvajes>
La sintaxis tiene la forma: REPOSITORYNAME / BRANCH. Además, BRANCH se reconoce como una abreviatura de * / BRANCH, '*' se reconoce como un comodín y '**' se reconoce como un comodín que incluye el separador '/'. Por lo tanto, origen / ramas * coincidiría con origen / ramas-foo pero no origen / ramas / foo, mientras que origen / ramas ** coincidiría con origen / ramas-foo y origen / ramas / foo.
: <expresión regular>
La sintaxis tiene la forma:: regexp. La sintaxis de expresión regular en las ramas para compilar solo creará aquellas ramas cuyos nombres coincidan con la expresión regular.
Ejemplos:
: ^ (?! (origen / prefijo)). *
coincidencias: origen u origen / maestro u origen / característica
no coincide: origen / prefijo u origen / prefijo_123 o origen / prefijo-abc
: origen / lanzamiento- \ d {8}
coincidencias: origen / lanzamiento-20150101
no coincide con: origen / lanzamiento-2015010 o origen / lanzamiento-201501011 o origen / lanzamiento-20150101-algo
: ^ (?! origen / maestro $ | origen / desarrollo $). *
coincidencias: origen / rama1 o origen / rama-2 o origen / maestro123 o origen / desarrollo-123
no coincide: origen / maestro u origen / desarrollo
Entonces, cuando desee especificar una rama específica para extraer, los mejores cuatro métodos de escritura inequívocos son:
refs / heads / <branchName>
refs / remotes / <remoteRepoName> / <branchName>
refs / tags / <tagName>
<commitId>
El problema básico aquí es la verdad. Fui a gitlab y miré la lista de ramas de este proyecto, y descubrí que realmente hay una rama llamada origin / qa. Después de la confirmación con otros colegas, alguien creó este origen / qa con un apretón de manos. Rama.
Puse el original * / qa reemplazado refs / Heads / qa , por lo que coincidió con precisión con la rama específica. Intente activar la compilación del trabajo nuevamente. Esta vez, la versión del código de Git descargada también es correcta.
Este artículo es una historia original de pisar el foso. Si te resulta útil, déjame un me gusta, ¡gracias!
Blogger: prueba para ganar dinero
Lema: completa la acumulación original a través de una carrera de prueba y avanza hacia la libertad financiera a través de la inversión
csdn: https://blog.csdn.net/ccgshigao
Blog Park: https://www.cnblogs.com/qa-freeroad/