Does anyone understand how does jenkins manage its queue_id ?
I checked there is a queue.xml in jenkins folder and the attribute “counter” is being used as the queue id
The reason I am asking this is that the queue_id in jenkins is being reset/changed on its own . This occurred when I enabled discard old build in pipeline and I am not sure that enabling it will cause the queue_id to be reused .
My question is there a way to set the queue id like setting the next build number and there any settings that needs be enabled or disabled to resolve this .
Hello @jun and welcome to this community.
In Jenkins, the queue ID (also known as build number or build ID) is a unique identifier assigned to each build or job that is placed in the build queue. This ID is used to differentiate and track builds. The
queue.xml file you mentioned is used to store information about the queued items in Jenkins, and the
counter attribute within this file is used to keep track of the next available queue ID.
Regarding your specific issue of the queue ID being reset or changed, there might be a few points to consider:
- Discard Old Builds: The “Discard Old Builds” feature in Jenkins allows you to limit the number of builds retained for a particular job or pipeline. Enabling this feature doesn’t directly affect the queue IDs of new builds. It only manages the builds that have already been executed and are no longer needed.
- Queue IDs and Build Numbers: Queue IDs and build numbers are generally unrelated. Queue IDs are assigned when a job or pipeline is placed in the build queue, while build numbers are assigned when the job actually starts executing. Queue IDs are typically unique for each queued item, whereas build numbers are unique within the context of a specific job.
- Queue Reuse: Queue IDs may be reused, especially if the queue item was canceled or deleted before it started building. Jenkins will reuse queue IDs when necessary.
You could also have a look at the Next Build Number plugin.
Thank you for your response.
Queue Reuse: I’ve noticed in my database where I’ve come across two identical jobs with the same queue_id but different build_id. These entries were injected into the database a week apart, and both builds completed successfully.
The “Discard Old Build” feature, which seems to have concealed the queue_id for the first build. However, I can still retrieve the queue_id for the second build via the Jenkins API.
This raises a question: If it’s true that “Discard Old Build” does not impact the queue_id, how does Jenkins recognize and reuse the queue_id?
From what I understand, Jenkins doesn’t employ a database; rather, it stores information in a configuration file (.xml). In this context, the queue.xml file
If Jenkins indeed reuses the queue_id, it must be altering the queue.xml counter attribute. For instance, if the latest queue_id is 100, it might verify that 99 is unused and then update the counter attribute in queue.xml to 99. After a build was trigger the queue_id will be 100 which creates duplicate queue_id
The build_number can support a maximum of 2,147,483,647, as mentioned in this Stack Overflow post, I fail to see why Jenkins would need to reuse queue_id.
Could you please provide a more comprehensive explanation of how Jenkins handles queue_id reuse? Furthermore, if a user wishes to modify or update the queue_id, what is the recommended approach to achieve this?
I apologize, @jun, but I’ve shared all the information I have about build numbers and queue ids. I hope someone with more knowledge on this topic can provide further assistance.
The short answer is the queue_id is specifically this counter and is incremented by instantiating this class via super method of hudson.model.Queue.Item.
Jenkins doesn’t reuse it unless your system restarts or the counter overflows (unlikely).
If you want to know the full path refer to AbstractProject class schedulebuild2 method ultimately ending up in the Queue.schedule2 method.