[JENKINS-61046] - Allow plugins to force an update of the UpdateCenter

[jtnord]

See JENKINS-61046.

Proposed changelog entries

• Developer: Allow plugins to force an update of an UpdateSite

Proposed upgrade guidelines

N/A

Submitter checklist

• JIRA issue is well described
• Changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developer, depending on the change). Examples
  • Fill-in the Proposed changelog entries section only if there are breaking changes or other changes which may require extra steps from users during the upgrade
• Appropriate autotests or explanation to why this change has no tests
• For dependency updates: links to external changelogs and, if possible, full diffs

Desired reviewers

@mention

Maintainer checklist

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

• There are at least 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 does not block the change
• Changelog entries in the PR title and/or Proposed changelog entries are correct
• Proper changelog labels are set so that the changelog can be generated automatically
• If the change needs additional upgrade steps from users, upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the PR title. (example)
• If it would make sense to backport the change to LTS, a JIRA issue should exist and be labeled as lts-candidate

[oleg-nenashev]

Looks good to me in principle, but IMO we should avoid exposing test parameters in new API. I suggest to introduce a new API method which does not allow disabling the signature check. (may be off only for testing!) in Javadoc was a good first step, but IMHO it is not enough

[timja]

Looks good to me in principle, but IMO we should avoid exposing test parameters in new API. I suggest to introduce a new API method which does not allow disabling the signature check. (may be off only for testing!) in Javadoc was a good first step, but IMHO it is not enough

if we're introducing a new API then it would be good for it not to return form validation and either return a boolean or throw on error

[jtnord]

if we're introducing a new API then it would be good for it not to return form validation and either return a boolean or throw on error

@timja that would collide with the way I have just addressed @oleg-nenashev's feedback. internal non test code no longer call updateDirectly(boolean) or updateDirectlyNow(boolean) and changing the return would mean they would go back to calling the boolean parametered methods or a larger refactoring.

before I make any further changes could you both come to an agreement on the latest or disagree on the merits of 20a2c76

[timja]

It would be nice if an intended API didn’t return web specific form validation, but not blocking it

[oleg-nenashev]

Thanks @jtnord ! The current version looks good to me.

[oleg-nenashev]

Bonus points for restricting the external use

[jtnord]

that would break source compatibility, and that could break some (at least internal) workflows, as well as having the potential to force disabling the Restrictions check a for another year - which was the whole point of this PR to begin with.
Let's just at least deprecate it for at least a few LTS version first (we could/should start looking at doing a sweep of all deprecated API and look at restrict them based on how long they have been deprecated).

[oleg-nenashev]

Fine with me. We break compatibility too often in recent releases

[oleg-nenashev]

I suggest merging it tomorrow if no negative feedback