Add an updateLock step to alter resources in pipelines

[gaspardpetit]

This PR proposes to add a new updateLock step which can be used to alter the resource configuration. Maybe updateResource would be better, but I thought users of this plugin would find updateLock more intuitive.

With this change, the following can be altered:

• adding labels
• removing labels
• setting labels (replacing)
• setting the note
• creating new locks
• deleting existing locks

New locks are created persistent (non-ephemeral). The use case for this can be having a job that would configure the locks based on an external source (ex. scm). I have not yet figured out how the sync could remove invalid locks (we will probably need a way to list locks so the ones removed from scm can be deleted - open for discussion)

Deleted locks are set to ephemeral if currently locked.

Once #299 is in, I will submit another PR to allow properties to be altered as well.

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests - that demonstrates feature works or fixes the issue

[gaspardpetit]

I just realized the org.jenkins.plugins.lockableresources.LockableResourcesManager can be imported in groovy - so I think this step may not be necessary :D

[gaspardpetit]

I take this back, working straight on the org.jenkins.plugins.lockableresources.LockableResourcesManager is painful

[gaspardpetit]

I worked a bit more on this - so the original pipeline looks like this - using the LockableResourcesManager directly:

import org.jenkins.plugins.lockableresources.LockableResourcesManager as LRM
script {
  Map resources = readYaml(file: 'resources.yaml')

  resources.each { k, v ->
    LRM.get().createResource(k)
    def r = LRM.get().fromName(k)
    r.setEphemeral(false)
    if (v.labels) {
      r.setLabels(v.labels.join(" "))
    }
    else {
      r.setLabels("")
    }
  }

  def allResources = LRM.get().getResources();
  List toBeDeleted = []
  for (resource in allResources) {
    if (resources.keySet().contains(resource.getName()) == false) {
      toBeDeleted += resource
    }
  }

  for (toDelete in toBeDeleted) {
    LRM.get().getResources().remove(toDelete)
  }

  LRM.get().save()
}

With this propose change, I am simplifying it down to

script {
  Map resources = readYaml(file: 'resources.yaml')

  resources.each { k, v ->
    updateLock(resource:k, createResource:true, setLabels:(v.labels?:[]).join(" "))
  }

  def allResources = LRM.get().getResources();
  List toBeDeleted = []
  for (resource in allResources) {
    if (resources.contains(resource.getName()) == false) {
      toBeDeleted += resource
    }
  }

  for (toDelete in toBeDeleted) {
    updateLock(resource: toDelete, deleteResource:true)
  }
}

After this change, the step I'd be missing would be a findLocks step - then I could go

script {
  Map resources = readYaml(file: 'resources.yaml')

  resources.each { k, v ->
    updateLock(resource:k, createResource:true, setLabels:(v.labels?:[]).join(" "))
  }

  for (resource in findLocks()) {
    if (resources.contains(resource.name) == false) {
      updateLock(resource: toDelete, deleteResource:true)
    }
  }
}

[jimklimov]

I haven't mastered step creation yet, so this PR looks great to me (possibly also as a pattern/checklist to look up to in the future) and has it all - with UI, help and tests included :)

[DonnieKim411]

Any update on this? this feature will be super useful for our use case... in fact, many PR requests by @gaspardpetit are exactly what I am looking for to fully adopt this plugin.

[mPokornyETM]

the user shall be inform about that

• in the job log
• in the UI like setting some other description. ( in this case I will not change note, labels) Just set ephemeral = true.

One hit more. What happens, when other job is waiting for this resource? This one will be on release deleted. The next one will create it again, or in worst case crashed the job.