Hosting for a new plugin

[Stuart Davidson]

Hi there,

I'd like to use the official Jenkins repo to publish a new plugin for executing a build remotely.

The plugin allows you to request a build from the API but it returns a JSON snippet with a UUID for the job. This allows you to track the status of a job (using another part of the API) even before it has left the queue and has been assigned a run id - being in the queue is a valid state.

I've found it very useful for executing batches (100+) of the same job but with different parameters, then tracking the status of them as they get completed.

Please could you create a jenkins/job-run-uuid repo in Github, my github id is spedge.

I'm also happy to listen to any suggestions or recommendations for this :)

Thanks,

Stuart

[Ulli Hafner]

New github repository created at https://github.com/jenkinsci/job-run-uuid-plugin

Welcome aboard!

Ulli

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Vincent Latombe]

Hi Stuart,

some pinged me today about your plugin, it appears very useful. Maybe it could be worth to release it properly to have more people know about it and let them install it directly from the plugin manager?

If you need some help with that I can give a hand.

Cheers,

Vincent

[Stuart Davidson]

Hi Vincent!

Thanks for getting in touch. Yeah, I always meant to get round to officially releasing it - the code was here, I was just tidying it up.

If you want to pass my e-mail along, I can talk to them directly and make sure it does what they are looking for.

Stu

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/8nph2HKmiJA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Beck]

On 21.11.2013, at 20:01, Stuart Davidson <stuart....@spedge.com> wrote:

> The plugin allows you to request a build from the API but it returns a JSON snippet with a UUID for the job. This allows you to track the status of a job (using another part of the API) even before it has left the queue and has been assigned a run id - being in the queue is a valid state.

How is this plugin different from the queue item API whose ID/location is provided in the Location header from /build?

[Stuart Davidson]

I've not touched this in a while Daniel, but I found that if I was queuing multiple copies of the same job, I could give it a unique ID - whereas /build simply gives you the information it's queuing. 

That's not to say that the queue API has improved to include information like this - like I say, it's been a while :)

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/8nph2HKmiJA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.

[Daniel Beck]

On 31.07.2014, at 12:19, Stuart Davidson <stuart....@spedge.com> wrote:

> I've not touched this in a while Daniel, but I found that if I was queuing multiple copies of the same job, I could give it a unique ID - whereas /build simply gives you the information it's queuing.
>
> That's not to say that the queue API has improved to include information like this - like I say, it's been a while :)

This was changed for parameterized builds in 1.561 to match the behavior for unparameterized builds. Example how the core API works is in this Jira comment:

https://issues.jenkins-ci.org/browse/JENKINS-12827?focusedCommentId=201381&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-201381

[Stuart Davidson]

As I understand it, a build could be queued, cancelled, queued again and thus end up with the same build id. With this plugin, I'm appending a UUID to the build in order to identify a unique run no matter what happened in the queue.

However, you've shown a way of uniquely identifying a build by using the inQueueSince information under Location which would probably do the same thing. If you check build 25 and it's got a different inQueueSince, you can assume it's not the droid you are looking for.

Nothing is likely to change the inQueueSince once a build joins a queue, is it?

[Daniel Beck]

On 31.07.2014, at 12:36, Stuart Davidson <stuart....@spedge.com> wrote:

> As I understand it, a build could be queued, cancelled, queued again and thus end up with the same build id. With this plugin, I'm appending a UUID to the build in order to identify a unique run no matter what happened in the queue.
>
> However, you've shown a way of uniquely identifying a build by using the inQueueSince information under Location which would probably do the same thing. If you check build 25 and it's got a different inQueueSince, you can assume it's not the droid you are looking for.
>
> Nothing is likely to change the inQueueSince once a build joins a queue, is it?

Queue item ID is NOT the build number (that's basically the whole point of my Jira comment). It's unique Jenkins-wide, probably similar to your UUID.

As you can see in the last XML snippet, it will even tell you information about queue items that are no longer in the queue (<leftItem>, the build number is at <executable/>). If cancelled from the queue, it'll be <canceled>true</canceled> and not have an executable.

[Stuart Davidson]

So that identifier, in the example, is queue id 25. If the job is queued, cancelled and queued again, a new identifier (26) will be used. Once a job leaves the queue and is building, that queue id is still accessible using the same restful interface and the build number is now under the <executable> tag.

If that's the case, this plugin is redundant - you can do all you need to do within the queue api.

Can I ask if this is particularly new, or has it been around for a while - if so, when did it come in?

[Vincent Latombe]

Daniel said 1.561, so this is in the latest LTS, which is great!

Vincent

--

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.