Ho iniziato a sperimentare con Hudson come server di build. Sto usando la sovversione e l'ho configurato per eseguire il polling ogni minuto. Il problema che sto vedendo è che se una build alla revisione 10 richiede 5 minuti e ci sono 5 commit in quel periodo, Hudson realizzerà la versione successiva 15.È possibile configurare Hudson per compilare ogni revisione?
C'è un modo per garantire che ogni revisione sia stata costruita?
Hudson non ha ancora questa capacità, ma è stato chiesto alcune volte sulla mailing list. Vedere issue 673
Ho cercato quell'errore. Il bug tracker si è spostato, il problema è ora a http://issues.hudson-ci.org/browse/HUDSON-673 ed è ancora irrisolto. – Bluehorn
Grazie. Ho aggiornato il link. –
In parte SCM di configurazione di generazione si dovrebbe avere Corporatura Trigger sezione e l'opzione "Trigger costruisce a distanza (per esempio, da script)". In base alle informazioni della guida accanto a tale opzione è possibile eseguire lo script dell'azione post-commit in modo che ogni commit possa generare nuove build. Siccome hudson ha una coda di build dovresti avere tutte le revisioni costruite.
Ecco un link che potrebbe aiutare: https://hudson.dev.java.net/build.html
Ecco ad esempio come iniziare lavoro composto con i parametri (vedi al mio commento per i dettagli): http://wiki.hudson-ci.org/display/HUDSON/Parameterized+Build
Non sono sicuro che funzionerà direttamente - il primo commit attiverà una build, quindi 3 commit trigger 3 ulteriori build prima della prima. Sfortunatamente, la seconda build in coda eseguirà quindi un aggiornamento e creerà la versione più recente, così come i seguenti build. Cosa è necessario per poter passare un numero di revisione alla richiesta di compilazione e avere quel numero usato durante l'aggiornamento. –
Hai ragione, non ho pensato a quello scenario ovvio. Ma come ho visto nella documentazione di hudson, è possibile richiamare il lavoro di build con i parametri in modo da poter definire il parametro stringa di build RevisionToBuild e impostarlo dallo script in questo modo: "http: // server/job/myjob/buildWithParameters? RevisionToBuild = 1234 "e, naturalmente, modificare correttamente il percorso del repository svn per utilizzare quel parametro. – grapkulec
Ma è possibile fare in modo che il processo di costruzione accoda un solo lavoro in profondità (per un determinato esecutore di build il "numero di esecutori") e questo otterrà il risultato che si sta cercando ... anche se le build parallele sarebbero più veloci. – MattyT
Bisogna fare alcune cose per costruire esattamente ogni revisione:
REVISION stringa per il vostro lavoro${REVISION} per l'URL del repository, https://server/path/myproject${REVISION}REVISION viene espansa solo nella URL, ma quando si crea la cartella, Hudson non si espanderlo, resu lting in una cartella denominata: myproject${REVISION} /usr/bin/wget \ --auth-no-challenge \ --no-check-certificate \ --user=me \ --password=mypasswd \ https: //server/path/job/jobname/buildWithParameters?delay=0sec\&REVISION=%40$REV \ -O /dev/null Se si desidera attivare una build manualmente, avete due possibilità:
Il @ segno è molto importante perché tutto questo trucco si basa sul fatto che Subversion plug interpreta [email protected] come get revision NNN from repository at URL. Se si dimentica il @, Subversion sarà solo dire che non riesce a trovare la cartella https://server/path/myprojectNNN. Questo è anche il motivo devi mettere %40 tra REVISION= e $REV nel comando wget, %40 è il carattere di escape per @.
La chiave per assicurarsi che ogni commit è costruito in Hudson è "Costruire con parametri" e solo se grilletto costruire con diversi valori di parametro, Hudson pensare che sia nuova costruzione e dovrebbe essere tenuto in coda di costruzione.O non sarà registrato da Hudson in quanto ritiene Costruiamo insignificante rispetto al precedente
esempio puoi fare clic su "Build Now" per attivare la build per tre volte e lasciare il par build come "null". vedrai solo le prime due build nella coda di Hudson. Il terzo sarà ignorato: P cool ma è davvero brutto che non si trovi in qualche documento ma con i miei esperimenti per i tempi :(
Ho seguito l'approccio fasullo sopra (grazie man!) E l'ho modificato per funzionare con Mercurial.
È necessario modificare .hg/hgrc sul server centrale e inserire un hook di changegroup. Tenere presente che i changegroups impostano solo il primo changeset sulla variabile di ambiente HG_NODE, quindi è necessario eseguire un hg tip su prendi il vero nodo tip e passa quello tramite URL.)
Questo è quello che faresti per Hudson in esecuzione su Windows.
[hooks]
# this uses wget to hit the hudson url responsible for starting a build - %HG_NODE% only gets first changeset of changegroup, so use hg tip to grab changeset most recently added instead
changegroup.hudson = for /f "tokens=*" %G IN ('hg tip --template {node}') DO "C:\Program Files (x86)\UnxUtils\usr\local\wbin\wget" --non-verbose --spider http://HudsonServer:8080/job/{Repository}/buildWithParameters?HgRevId=%G | ECHO Result of Hudson Polling Request For Node %G
# TODO: when Hudson implements polling with parameters, change to something like this
#changegroup.hudson = for /f "tokens=*" %G IN ('hg tip --template {node}') DO "C:\Program Files (x86)\UnxUtils\usr\local\wbin\wget" --non-verbose --spider http://HudsonServer:8080/job/{Repository}/polling?HgRevId=%G | ECHO Result of Hudson Polling Request For Node %G
È necessario fare attenzione che questo non causi problemi di prestazioni per Hudson. Ad esempio, se si verificano dei commit ogni pochi secondi, mentre una build hudson richiede alcuni minuti. Presto invaderai la coda di costruzione. – toolkit
Per la vita di me, non riesco a capire perché questo potrebbe essere necessario. Perché qualcosa di diverso dallo stato attuale della base di codice dovrebbe essere importante? – sal
Salve, la ragione di ciò è il test. Miriamo a mettere ogni revisione attraverso un test di regressione. Quindi, se non stiamo costruendo ogni revisione, non stiamo testando ogni revisione. Questo causa problemi se rev n funziona ma rev n + 10 non lo è e non abbiamo testato nessuna delle revisioni tra. Quale cambiamento ha causato la regressione? – CodeBuddy