Configure un trabajo de Jenkins para no clonar el repositorio en SCM

17

He integrado Jenkins con Bitbucket usando el complemento Bitbucket . Según la Wiki del complemento, un trabajo determinado se activará si el repositorio se establece en el SCM del trabajo. Como sabe, si uno configura SCM en un trabajo de Jenkins, esto se clona en la etapa previa a la compilación.

Hasta aquí todo bien. Sin embargo, el propósito principal del trabajo que estoy estableciendo no tiene nada que ver con el contenido del repositorio; en cambio, solo quiero que el trabajo procese la carga útil enviada por Bitbucket. Se podría decir que no es un gran problema en términos de almacenamiento clonar un repositorio a pesar de que realmente no lo necesita. No lo creo, agregar pasos innecesarios, consumir tiempo y recursos no es una buena práctica.

Entonces, la pregunta es: ¿Alguien sabe cómo configurar un SCM en un trabajo de Jenkins pero evita que clone el repositorio?

Héctor Valverde Pareja
fuente
2
Parece que estás tratando de usar Jenkins como un micro servicio que está fuera del alcance de Jenkins :). Sin embargo, vuelva a publicar si consigue que esto funcione porque es interesante.
Travis Thompson
No estoy usando Jenkins como un micro servicio. ¿Por qué dices eso? En realidad, todo esto es una solución: estoy usando un trabajo de canalización que es común en muchos repositorios. Jenkinsfile está en un repositorio diferente. Por lo tanto, no puedo activar la canalización directamente con el complemento Bitbucket porque simplemente no lo activa, por lo que decidí crear un "trabajo proxy" por repositorio y enviar la información a la canalización como un trabajo posterior. En ese "trabajo de proxy" no necesito clonar el repositorio, pero debe estar en SCM.
Héctor Valverde Pareja
Es muy difícil de entender y escribes más sobre lo que es imposible que sobre lo que realmente quieres lograr. ¿Quizás puedas agregar más detalles sobre lo que realmente quieres lograr y cómo encajan tus trabajos proxy?
Michael Le Barbier Grünewald
Supongo que estás hablando de mi comentario anterior. Es solo una respuesta al primer comentario. Consulte la pregunta principal, no hay nada más que agregar. Lo que quiero que logre es muy claro: "Evite que Jenkins clone un repositorio durante la compilación".
Héctor Valverde Pareja
1
@ HéctorValverdePareja Claro, pero su redacción parece dudar entre A / dar suficientes detalles para que todos puedan verificar si se encuentra en una situación de problema XY y B / solo para centrarse en lo preciso que desea lograr. Creo (opinión) que podría eliminar esta duda describiendo con cuidado su problema original y la solución que está tratando de implementar. Pero ahora que alguien escribió una respuesta, esto podría no ser tan importante.
Michael Le Barbier Grünewald

Respuestas:

18

Sí definitivamente. Hago esto todo el tiempo. Puede especificar las opciones de configuración para su canalización y una de ellas es la skipDefaultCheckoutque hace que la canalización omita la etapa predeterminada "Declarativo: Pago y envío SCM".

La skipDefaultCheckoutopción está documentada en Sintaxis de canalización y aquí hay un ejemplo de Jenkinsfile que muestra cómo usarla:

pipeline {
  agent { label 'docker' }
  options {
    skipDefaultCheckout true
  }
  stages {
    stage('commit_stage') {
      steps {
        echo 'sweet stuff here'
      }
    }
  }
}
Burnettk
fuente
1
¿Cómo lo harías? ¿Clonar manualmente el repositorio en una etapa?
Oz123
2
puede ejecutar checkout scmpara clonar manualmente donde lo necesite. ver devops.stackexchange.com/a/1916/2450 .
burnettk
5

En caso de que no esté utilizando la canalización declarativa, puede evitar el pago desde SCM:

node {
        skipDefaultCheckout()
        //...
}
usuario3118604
fuente
1
¿Podría agregar un enlace a la documentación y explicar más sobre skipDefaultCheckout ()?
030
No veo ningún valor agregado en comparación con la respuesta existente, eso es solo un 'intente esto' sin explicación y no es una buena respuesta.
Tensibai
Esta respuesta está bien como un complemento de la respuesta aceptada: no todos usarán el complemento de Pipeline declarativo, por lo que esto funciona para aquellos que usan el procedimiento.
RichVel
1

Creo que lo que quieres lograr es procesar una carga útil de webhook en un trabajo de Jenkins. El uso del complemento bitbucket no será necesario y probablemente esté fuertemente diseñado para clonar el repositorio.

Creo que esta respuesta de stackoverflow podría ayudarte.

Fanch
fuente
Incluya una cita relevante de esa respuesta vinculada ...
Pierre.Vriens
1
¡Bienvenido a DevOps! Si bien esto puede responder teóricamente la pregunta, sería preferible incluir aquí las partes esenciales de la respuesta y proporcionar el enlace para referencia.
Richard Slater
@RichardSlater No estoy seguro acerca de la política en DevOps, pero otros sitios hacen una excepción para los enlaces dentro de la red.
pollitos
3
@chicks, incluso los enlaces StackOverflow están sujetos a la descomposición del enlace y, al resumir la pregunta, da una indicación clara de otras razones por las cuales el respondedor cree que el enlace responde la pregunta.
Richard Slater