Shared Agent copies made with Move/Copy/Promote are not provisioned for concurrent builds

Jobs that request a Shared Agent by label do not each get an agent provisioned when multiple builds run concurrently. One build acquires the agent and runs, while the other builds that request the same label remain queued, even though multiple identically labeled Shared Agent items appear online and connected.

One root cause of this provisioning failure is duplicating a Shared Agent with Move/Copy/Promote. Using Move/Copy/Promote to copy or move a Shared Agent item creates a copy that retains the same internal UID as the original. The operations center uses this UID to track agent leases, so Shared Agent items that share a UID are treated as a single lease target. Both the original and the copy can connect and show as online, but only one of them can be leased out at a time.

Jenkins core item copy already blocks duplicating a Shared Agent. The Move/Copy/Promote feature does not do the same check, so it can create a Shared Agent copy that the standard Jenkins copy operation would have rejected. Because the copy keeps the original Shared Agent’s UID, and the operations center uses the UID to track leases, the two Shared Agent items are leased as if they were one, so only one can be on lease to a controller at any given time even though both show as connected.

SSH-launched Shared Agents copied this way are also affected in another way: the copy targets the same host as the original, since the SSH connection details are copied along with the UID.

Move/Copy/Promote will be updated to disallow copying of the Shared Agent items. See workaround below.