Je suis capable de l'utiliser avec succès pour lancer un travail Jenkins:
curl -X POST "http://jenkins_srv:8080/job/MY_JOB/buildwithParameters?this=1&that=2" --user name:pass
Je peux également obtenir le consoleText de ce travail en utilisant:
curl -X POST "http://jenkins_srv:8080/job/MY_JOB/lastBuild/consoleText"
Cependant, cela n'évolue pas si j'exécute plusieurs tâches consécutivement. J'ai remarqué que la première commande curl a un retour qui comprend:
Location: http://jenkins_srv:8080/queue/item/123/
Je suppose que 123
est l'ID de la file d'attente des travaux.
Ma question est, si je file les travaux 121
, 122
, & 123
dos à dos, que dois-je utiliser pour vérifier l'état de l'élément de file d'attente des travaux 122
? En outre, que dois-je utiliser pour déterminer l'ID de build réel qui a finalement résulté de l'élément de file d'attente de travaux 122
?
Merci d'avance.
En supposant que vous avez un emplacement de http://jenkins_srv:8080/queue/item/123/
, vous pouvez GET http://jenkins_srv:8080/queue/item/123/api/json?pretty=true
pour renvoyer des informations sur cet élément de file d'attente (vous ne pouvez pas non plus inclure ?pretty=true
si vous ne vous souciez pas du formatage, ou utilisez api/xml
si vous voulez les résultats en XML).
Je ne sais pas s'il existe une documentation standard sur l'API de file d'attente, mais il semble que si l'élément de file d'attente est terminé (peut-être aussi s'il est en cours de construction?), Il aura un nœud executable
. Un pour mon serveur ressemblait à ceci:
"executable" : {
"_class" : "org.jenkinsci.plugins.workflow.job.WorkflowRun",
"number" : 10,
"url" : "http://192.168.99.100:32769/job/configure/10/"
}
Vous pouvez ensuite GET
l'API pour l'URL spécifiée dans executable.url
. Dans mon cas, GET http://192.168.99.100:32769/job/configure/10/api/json?pretty=true
. À partir de là, vous devriez avoir toutes les informations dont vous avez besoin, y compris si la construction est en cours de construction, combien de temps la construction a pris/a pris, le résultat, etc.
De plus, si vous souhaitez obtenir des informations sur l'ensemble de votre file d'attente de génération, vous pouvez GET http://jenkins_srv:8080/queue/api/json?pretty=true
J'ai choisi la réponse de Kdawg, car elle m'a aidé à me diriger dans la direction dont j'avais besoin. Je vous remercie!
J'inclus également ma propre réponse, car la solution que j'ai mise en œuvre était différente de la réponse de Kdawg, et je pense qu'elle apportera une valeur ajoutée à d'autres personnes.
Tout d'abord, je suis nouveau à Jenkins. Donc, si je me trompe, n'hésitez pas à me corriger. Deuxièmement, j'ai eu une légère courbe d'apprentissage en ce sens qu'il y a une différence entre un "élément de file d'attente" Jenkins et un "travail de génération" Jenkins. À l'instant où un "élément de file d'attente" a été créé, il n'y a pas d'ID de "travail de génération", car aucun travail de construction n'a démarré. De plus, une fois qu'un travail de génération a démarré, l'élément de file d'attente dispose de 5 minutes avant d'être supprimé.
Lorsque j'exécute ces tâches:
curl -X POST "http://jenkins_srv:8080/job/MY_JOB/buildwithParameters?this=1&that=2" --user name:pass
curl -X POST "http://jenkins_srv:8080/job/MY_JOB/buildwithParameters?this=1&that=2" --user name:pass
curl -X POST "http://jenkins_srv:8080/job/MY_JOB/buildwithParameters?this=1&that=2" --user name:pass
Jenkins programmera 3 tâches de build à exécuter dans une file d'attente. Ce seront des "éléments de file d'attente". Ces "éléments de file d'attente" auront un "ID de file d'attente". Dans l'exemple donné dans ma question d'origine, supposons que ces trois commandes curl créent des "éléments de file d'attente" avec "ID de file d'attente" s 121
, 122
, & 123
.
Pourquoi est-ce important?
Parce que selon la charge de votre serveur Jenkins, l'élément qui a été mis en file d'attente peut ou non être exécuté immédiatement. S'il s'exécute immédiatement, la réponse de Kdawg est certainement correcte. Exécuter ses commandes:
curl -X GET http://jenkins_srv:8080/queue/item/121/api/json?pretty=true --user name:pass
curl -X GET http://jenkins_srv:8080/queue/item/122/api/json?pretty=true --user name:pass
curl -X GET http://jenkins_srv:8080/queue/item/123/api/json?pretty=true --user name:pass
Cela obtiendra des informations de file d'attente sur chaque "élément de file d'attente", et dans ce qui retourne, il existe certainement un moyen d'obtenir un ID de "travail de génération", si le travail de construction a commencé. Si un travail de génération n'a pas encore commencé, ces informations seront vides.
Voici la partie supplémentaire qui, je pense, ajoute de la valeur.
Une fois qu'un travail de construction a commencé, les informations contenues dans la réponse de Kdawg seront renseignées dans la réponse aux trois curl -X GET
commandes. En outre, par défaut, Jenkins est conçu pour nettoyer (collecte des ordures, choisissez votre propre terme) les "éléments de file d'attente" toutes les 5 minutes. En d'autres termes, si tout ce que vous avez est un ID "élément de file d'attente" et que la fenêtre de conservation des données de 5 minutes passe, alors vous avez besoin d'un autre mécanisme afin d'obtenir un ID de "tâche de construction" à partir d'un ID "élément de file d'attente".
Donc, dans mon cas, j'utilise Jenkins comme frontal et Ansible à l'arrière pour effectuer la configuration du serveur et les déploiements d'applications. Certains de ces déploiements d'applications peuvent prendre 30 minutes ou plus, bien au-delà de la période de conservation des données de 5 minutes des "éléments de file d'attente".
Donc, le problème que j'ai dû résoudre, si tout ce que j'ai, c'est un ID "élément de file d'attente", alors comment puis-je trouver un ID de "travail de génération", quel que soit le moment où je vérifie, quelques secondes plus tard ou des heures plus tard?
Voici ma solution (notez que j'avais besoin d'une sortie XML, FYI).
J'ai exécuté cette commande:
curl -X POST "http://jenkins_srv:8080/job/MY_JOB/buildwithParameters?this=1&that=2" --user name:pass
Cette commande retournerait ces informations:
Runtime responseHeaders Date: Day, ## Non Year xx:yy:zz GMT
X-Content-Type-Options: nosniff
Location: http://jenkins_srv:port/queue/item/123/
Content-Length: 0
Server: Jetty(9.4.z-SNAPSHOT)
À partir d'ici, je peux analyser 123
dans le champ Location
.
J'ai ensuite dormi 10 secondes. Après le sommeil, j'exécute cette commande sur une boucle de 10 secondes:
curl -X GET http://jenkins_srv:8080/queue/item/123/api/xml
Je l'ai fait jusqu'à ce que je:
La boucle de cette manière gère un serveur Jenkins surchargé qui est lent à gérer les demandes de file d'attente. Donc, probablement si j'arrive à la fin des 10 minutes, mon approche traitera toujours le cas d'utilisation que mon approche d'automatisation a réussi à mettre en file d'attente et à exécuter le travail, mais il vérifie Jenkins en dehors de la fenêtre de conservation des données. Dans ce cas, j'exécuterais cette commande:
curl -X GET http://jenkins_srv:port/job/MY_JOB/api/xml?tree=builds[id,number,result,queueId]&xpath=//build[queueId=123]
Cela renvoie les informations XML pour tout "travail de génération" qui contient également un queueId
de 123
, comme indiqué ci-dessous:
<?xml version="1.0"?>
<build _class="hudson.model.FreeStyleBuild">
<id>456</id>
<number>456</number>
<queueId>123</queueId>
<result>SUCCESS</result>
</build>
De cette façon, j'ai pu obtenir avec autorité un ID de "travail de génération" tout en n'ayant qu'un ID "d'élément de file d'attente", quelle que soit la différence de temps entre le moment où j'ai commencé et le moment où j'ai vérifié.
Étonnant que Jenkins ne suive pas une demande jusqu'à sa conclusion avec un identifiant unique.
Un élément qui persiste entre l'élément mis en file d'attente et l'élément de génération est la liste des paramètres. Si vous avez la capacité/l'autorité de modifier la configuration des travaux, ajoutez un paramètre facultatif REQUEST_ID que le client arrache de l'air (par exemple un UUID) et passe par-dessus REST. Ensuite, vous pouvez interroger la file d'attente et rechercher celle avec votre REQUEST_ID, et vous pouvez interroger la liste des versions et rechercher celle avec votre REQUEST_ID.