[JENKINS-72170] fix nested hetero-list entries with mixture of inputs and buttons

[mawinter69]

when a plugin defines the hetero-list elements on its own and still uses an <input type="button"> element and an inner element is already using a hetero-list with a <button> element, then the old input wasn't converted to a button as the inner button was selected as the target. Avoid this by converting all inputs to buttons before actually looking up the button.

See JENKINS-72170.

Testing done

Manually tested as described in JENKINS-72170 that the button is working properly with this fix

Proposed changelog entries

• Fix multibranch Pipeline "Add source" and other uses that mix inputs and buttons (regression in 2.422).

Proposed upgrade guidelines

N/A

Submitter checklist

Preview Give feedback

1. The Jira issue, if it exists, is well-described.
2. 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). Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
3. New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
4. New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
5. New or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives (see documentation).
6. For dependency updates, there are links to external changelogs and, if possible, full differentials.
7. For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

N/A

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

Maintainer checklist

• There are at least two (2) approvals 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.
• 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).
• If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[basil]

The PR description does not address whether or not it is desired for plugins to include the hetero-list adjunct. If it is not desired, then the warning is justified and the plugins should be migrated.

[mawinter69]

the file is not needed anymore and plugins can just remove the inclusion of the adjunct once they require Jenkins 2.422 or newer
So removing it again

[basil]

Thank you for the quick fix and the thorough testing.

[MarkEWaite]

Thanks very much for the rapid response to the issue. I tested with a local build and confirmed that the case I had tested for JENKINS-72170 is resolved.

[MarkEWaite]

This PR is now ready for merge. We will merge it after approximately 24 hours if there is no negative feedback.

/label ready-for-merge

[timja]

should there be a deprecation warning logged to get developers to adapt code?

[MarkEWaite]

@timja would you be OK if this were merged without the deprecation warning or would you strongly prefer that the deprecation warning be added before it is merged?

I'd like to be sure this is included in the next weekly so that it is a strong candidate for a backport to the Nov 15, 2023 LTS baseline.

[MarkEWaite]

I merged with the assumption that we can add the deprecation message in a later pull request