secret - Git-¿Qué es "Refspec"
gitlab secret token jenkins (1)
He estado siguiendo esta guía sobre la configuración de la integración continua de GitLab con Jenkins.
Como parte del proceso, es necesario configurar la respuesta de la siguiente manera:
+refs/heads/*:refs/remotes/origin/* +refs/merge-requests/*/head:refs/remotes/origin/merge-requests/ *
Por qué esto es necesario no se explica en la publicación, así que comencé a buscar en línea una explicación y consulté la documentación oficial , así como algunas preguntas relacionadas sobre el desbordamiento de pila como esta .
A pesar de esto, todavía estoy confundido -
¿Qué es exactamente refspec?
¿Y por qué es necesaria la refspec anterior? ¿Qué hace?
Un refspec le dice a git cómo asignar referencias desde un control remoto al repositorio local.
El valor que listó fue +refs/heads/*:refs/remotes/origin/* +refs/merge-requests/*/head:refs/remotes/origin/merge-requests/* ; así que vamos a romper eso.
Tienes dos patrones con un espacio entre ellos; Esto solo significa que estás dando múltiples reglas. (El libro de pro git se refiere a esto como dos refspecs; lo que probablemente sea técnicamente más correcto. Sin embargo, casi siempre tiene la capacidad de enumerar múltiples refspecs si es necesario, por lo que en la vida cotidiana es probable que haya poca diferencia)
El primer patrón, entonces, es +refs/heads/*:refs/remotes/origin/* que tiene tres partes:
El + significa aplicar la regla sin fallar incluso si al hacerlo se movería una referencia de destino de una manera que no sea de avance rápido. Volveré a eso.
La parte antes del : (pero después del + si hay uno) es el patrón "fuente". Eso es refs/heads/* , lo que significa que esta regla se aplica a cualquier referencia remota bajo refs/heads (es decir, sucursales).
La parte después de la : es el patrón de "destino". Eso es refs/remotes/origin/* .
Por lo tanto, si el origen tiene un master rama, representado como refs/heads/master , esto creará un origin/master referencia de rama remoto representado como refs/remotes/origin/master . Y así sucesivamente para cualquier nombre de rama ( * ).
Así que volviendo a eso + ... supongamos que el origen tiene
A --- B <--(master)
Usted busca y, aplicando que refspec obtiene
A --- B <--(origin/master)
(Si aplicó las reglas de seguimiento típicas e hizo un pull , también tiene un master apuntando a B )
A --- B <--(origin/master)(master)
Ahora algunas cosas pasan en el control remoto. Alguien quizás hizo un reset que borró B , luego cometió C y luego forzó un empuje. Así que el mando a distancia dice
A --- C <--(master)
Cuando te traes, obtienes
A --- B
/
C
y git debe decidir si permite el movimiento de origin/master de B a C Por defecto, no lo permitiría porque no es un avance rápido (le diría que rechazó el impulso para esa referencia), pero como la regla comienza con + , lo aceptará.
A --- B <--(master)
/
C <--(origin/master)
(En este caso, un tirón resultará en una confirmación de fusión).
El segundo patrón es similar, pero para merge-requests referencias de merge-requests (que asumo que están relacionadas con la implementación de PR de su servidor; no estoy familiarizado con él).
Más sobre refspecs: https://git-scm.com/book/en/v2/Git-Internals-The-Refspec