Plugin Git Jenkins: come creare un tag specifico?

Ho problemi a convincere Jenkins a creare un tag specificato. Il tag fa parte di una build parametrizzata, ma non so come passarlo al plugin git per creare solo quel tag. Ci sono volute 3 ore della mia giornata e ho concesso la sconfitta ai master allo stack overflow.

Sono stato in grado di farlo utilizzando il parametro "branch to build":

Branch Specifier (blank for default): tags/[tag-name]

Sostituisci [nome-tag] con il nome del tuo tag.

Nessuna di queste risposte era sufficiente per me, utilizzando Jenkins CI v.1.555, plug-in Git Client v.1.6.4 e plug-in Git 2.0.4.

Volevo un lavoro da costruire per un repository Git per un tag specifico, fisso (cioè non parametrizzato). Ho dovuto mettere insieme una soluzione dalle varie risposte più il post del blog "build a Git tag" citato da Thilo .

1. Assicurati di inviare il tag al repository remoto con git push --tags
2. Nella sezione "Repository Git" del tuo lavoro, sotto l'intestazione "Gestione codice sorgente", fai clic su "Avanzate".
3. Nel campo per Refspec, aggiungi il testo seguente: +refs/tags/*:refs/remotes/origin/tags/*
4. In "Branches to build", "Branch specifier", inserisci */tags/<TAG_TO_BUILD>(sostituendo <TAG_TO_BUILD>con il nome effettivo del tag).

L'aggiunta di Refspec per me si è rivelata fondamentale. Anche se sembrava che i repository git stessero recuperando tutte le informazioni remote per impostazione predefinita quando l'ho lasciato vuoto, il plugin Git non riusciva comunque a trovare il mio tag. Solo quando ho specificato esplicitamente "get the remote tags" nel campo Refspec il plugin Git è stato in grado di identificare e costruire dal mio tag.

Aggiornamento 2014-5-7 : Sfortunatamente, questa soluzione ha un effetto collaterale indesiderato per Jenkins CI (v.1.555) e il meccanismo di notifica push del repository Git à la Stash Webhook a Jenkins : ogni volta che qualsiasi ramo del repository viene aggiornato in un push, anche i processi di creazione dei tag verranno attivati ​​di nuovo. Ciò porta a molte ricostruzioni non necessarie degli stessi lavori di tag più e più volte. Ho provato a configurare i lavori sia con che senza l'opzione "Forza polling utilizzando lo spazio di lavoro" e sembrava non avere alcun effetto. L'unico modo per impedire a Jenkins di creare build non necessarie per i lavori con tag è cancellare il campo Refspec (ovvero eliminare il +refs/tags/*:refs/remotes/origin/tags/*).

Se qualcuno trova una soluzione più elegante, modifica questa risposta con un aggiornamento. Sospetto, ad esempio, che forse questo non accadrebbe se il refspec fosse specificamente +refs/tags/<TAG TO BUILD>:refs/remotes/origin/tags/<TAG TO BUILD>piuttosto che l'asterisco catch-all. Per ora, tuttavia, questa soluzione funziona per noi, rimuoviamo semplicemente Refspec extra dopo che il lavoro ha esito positivo.

Non puoi dire a Jenkins di costruire da un nome Ref? Se è così allora è

refs/tags/tag-name

Da tutte le domande che vedo su Jenkins e Hudson, suggerirei di passare a TeamCity. Non ho dovuto modificare alcun file di configurazione per far funzionare TeamCity.

Se stai utilizzando pipeline Jenkins e desideri controllare un tag specifico (ad esempio: un TAGparametro della tua build), ecco cosa puoi fare:

stage('Checkout') {
  steps {
    checkout scm: [$class: 'GitSCM', userRemoteConfigs: [[url: 'YOUR_GIT_REPO_URL.git', credentialsId: 'YOUR_GIT_CREDENTIALS_ID' ]], branches: [[name: 'refs/tags/${TAG}']]], poll: false
  }
}

In un ultimo Jenkins (1.639 e versioni successive) puoi:

1. basta specificare il nome del tag in un campo "Branches to build".
2. in una build parametrizzata puoi usare il parametro come variabile nello stesso campo 'Branches to build' cioè $ {Branch_to_build}.
3. puoi installare Git Parameter Plugin che ti fornirà funzionalità elencando tutti i rami e tag disponibili.

Ho fatto qualcosa di simile e ha funzionato:

Source Code Management

 Git    
    Repositories    


 Advance

Name: ref
Refspec : +refs/tags/*:refs/remotes/origin/tags/* 

 Branches to build  
 Branch Specifier (blank for 'any') : v0.9.5.2

Il registro di Jenkins ha confermato che stava ottenendo la fonte dal tag

Verifica della revisione 0b4d6e810546663e931cccb45640583b596c24b9(v0.9.5.2)

Ho impostato il campo Advanced-> Refspec su refs/tags/[your tag name]. Questo sembra più semplice dei vari altri suggerimenti per Refspec, ma ha funzionato bene per me.

AGGIORNAMENTO 23/7/2014 - In realtà, dopo ulteriori test, risulta che non ha funzionato come previsto. Sembra che la versione HEAD fosse ancora in fase di verifica. Si prega di annullare questa operazione come risposta accettata. Ho finito per ottenere una soluzione funzionante seguendo il post di gotgenes in questo thread (30 marzo). Il problema menzionato in quel post di attivazione non necessaria di build non era un problema per me, poiché il mio lavoro viene attivato da un lavoro a monte, non dal polling SCM.

AGGIORNAMENTO APR-2018 - Nota nei commenti che questo funziona per una persona e concorda con la documentazione di Jenkins.

Sono stato in grado di convincere Jenkins a creare un tag impostando Refspec e Branch Specifier come descritto in dettaglio in questo post del blog .

Ho anche dovuto impostare il nome del repository (su "origin" nel mio caso) in modo da poterlo fare riferimento in Refspec (altrimenti apparentemente userebbe un nome generato casualmente).

Quello che ho fatto alla fine è stato:

• ha creato un nuovo ramo jenkins-targete ha fatto in modo che Jenkins lo seguisse
• unisci da qualsiasi ramo o tag che voglio creare nel file jenkins-target
• una volta che la build funzionava, i test superati, ecc., crea semplicemente un tag dal jenkins-targetramo

Non sono sicuro che funzionerà per tutti, il mio progetto era piuttosto piccolo, non c'erano troppi tag e cose del genere, ma è estremamente facile da fare, non c'è bisogno di scherzare con refspec, parametri e cose del genere :-)

Puoi creare anche un tipo di tag, ad esempio 1.2.3-alpha43, utilizzando i caratteri jolly:

Refspec: +refs/tags/*:refs/remotes/origin/tags/*

Identificatore di ramo: origin/tags/1.2.3-alpha*

Puoi anche selezionare " Crea quando una modifica viene inviata a GitHub " per attivare il push, ma devi aggiungere l' azione "crea" al webhook

Aggiungendo i miei due centesimi qui poiché non ho visto una risposta che utilizza l'opzione "Build with parameters" in Jenkins.

Qui sto usando la console del browser CI di Jenkins per il progetto starwars_api e sono stato in grado di creare direttamente con "Build with parameters" con valore refs / tags / tag-name

1. scegli l'opzione "build with parameters".
2. aggiungi il valore nella casella come "refs / tags / tag_142" (tag_name = tag_142 per il mio esempio)

costruire con il nome del tag ref