[JENKINS-73835] Delete LockStepTest.deleteRunningBuildNewBuildClearsLock now that running builds may not be deleted

[dwnusbaum]

See JENKINS-73835, jenkinsci/jenkins#9810 (and specifically jenkinsci/jenkins#9810 (comment)). It is no longer possible to delete builds that are still running, so LockStepTest.deleteRunningBuildNewBuildClearsLock fails against Jenkins 2.481+.

I considered making the test perform a hard kill via WorkflowRun.doKill before deleting the build, but hard kills are already covered by various tests in https://github.com/jenkinsci/lockable-resources-plugin/blob/f310d75b5595c93593b0b81767e549389c8fea06/src/test/java/org/jenkins/plugins/lockableresources/LockStepHardKillTest.java, so I am proposing to just delete the test instead.

Testing done

I tried a few test changes against 2.481 before deciding to delete the test.

Proposed upgrade guidelines

N/A

Submitter checklist

• The Jira / Github issue, if it exists, is well-described.
• The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples).
  • The changelog generator for plugins uses the pull request title as the changelog entry.
  • Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during the upgrade.
• There is automated testing or an explanation that explains why this change has no tests.
• New public functions for internal use only are annotated with @NoExternalUse. In case it is used by non java code the Used by {@code <panel>.jelly} Javadocs are annotated.

• New or substantially changed JavaScript is not defined inline and does not call eval to ease the future introduction of Content Security Policy (CSP) directives (see documentation).
• For dependency updates, there are links to external changelogs and, if possible, full differentials.
• For new APIs and extension points, there is a link to at least one consumer.
• Any localizations are transferred to *.properties files.
• Changes in the interface are documented also as examples.

Maintainer checklist

Before the changes are marked as ready-for-merge:

• There is at least one (1) approval for the pull request and no outstanding requests for change.
• Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
• Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
• Proper changelog labels are set so that the changelog can be generated automatically. See also release-drafter-labels.
• If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
• java code changes are tested by automated test.

[jglick]

#35 FTR. Arguably more interesting would be a JenkinsSessionRule test that deletes the build on disk and then asserts that the system recovers after a restart.

[MarkEWaite]

I've labeled it as bug so that a release will be generated when it merges.

[jglick]

I've labeled it as bug so that a release will be generated when it merges.

@MarkEWaite use developer for this purpose.

[MarkEWaite]

@MarkEWaite use developer for this purpose.

I've added the developer label to the list of labels in the repository and have labeled this pull request with developer.

[jglick]

I've […] labeled this pull request with developer.

You have?

[mPokornyETM]

thanks to all for contribution

[MarkEWaite]

You have?

Apparently missed that final click to change the label. Will fix the changelog now...