Remove YUI

[timja]

See JENKINS-75100

Now that the disable by default of YUI has been released for ~1 month with no complaints its time to start thinking about removing YUI itself.

We're passed the baseline cut-off for the next LTS which was what @MarkEWaite requested that I wait for before removing YUI fully

What I've left:

• I've removed CSS where I think its safe but I haven't removed all mentions of yui.
• getYuiSuffix in Functions, there's a few plugins calling this which need cleaning up
• l:yui I've changed it to do nothing but its used in a few unmaintained plugins, I could remove this, thoughts?
• There's a few TODOs that say they could be cleaned up after yui was removed for the component, but hasn't been done yet

Testing done

Clicked around a number of pages and didn't see anything wrong.

Proposed changelog entries

• Remove the Yahoo! User Interface library

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. There is automated testing or an explanation as to why this change has no tests.
4. New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
5. New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
6. 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).
7. For dependency updates, there are links to external changelogs and, if possible, full differentials.
8. For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

@mention

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

Maintainer checklist

Preview Give feedback

1. There are at least two (2) approvals for the pull request and no outstanding requests for change.
2. Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
3. Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
4. Proper changelog labels are set so that the changelog can be generated automatically.
5. 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).
6. 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).

[MarkEWaite]

Thanks very much @timja! There are 8 plugins that have just been deprecated in update center as further preparation for this pull request. Only 1 of those plugins has more than 500 installs and it has less than 1000 installs. The pull request that deprecates the plugins is:

• deprecate plugins using YUI jenkins-infra/update-center2#833

I think that we need an entry in the LTS upgrade guide for this removal. We can pattern it after the text in the Prototype.js removal announcement.

[mawinter69]

we might have the one or other plugin that use the construct

<span class="yui-button">
  <button ...>
</span>

Those might look broken when we remove all the yui styling here.

[basil]

Not too many that matter, though. From my selection of checked-out open-source repositories:

atlassian-jira-software-cloud-plugin/src/main/resources/com/atlassian/jira/cloud/jenkins/config/JiraCloudPluginConfig/config.groovy
coverity-plugin/src/main/resources/jenkins/plugins/coverity/CIMStream/DescriptorImpl/defectFilters.jelly
electricflow-plugin/src/main/resources/org/jenkinsci/plugins/electricflow/ElectricFlowAssociateBuildToRelease/config.jelly
electricflow-plugin/src/main/resources/org/jenkinsci/plugins/electricflow/ElectricFlowDeployApplication/config.jelly
electricflow-plugin/src/main/resources/org/jenkinsci/plugins/electricflow/ElectricFlowPipelinePublisher/config.jelly
electricflow-plugin/src/main/resources/org/jenkinsci/plugins/electricflow/ElectricFlowRunProcedure/config.jelly
electricflow-plugin/src/main/resources/org/jenkinsci/plugins/electricflow/ElectricFlowTriggerRelease/config.jelly
hpe-application-automation-tools-plugin/src/main/resources/com/microfocus/application/automation/tools/model/ParallelRunnerEnvironmentModel/config.jelly
jira-ext-plugin/src/main/resources/org/jenkinsci/plugins/jiraext/view/AddLabelToField/config.jelly
jira-ext-plugin/src/main/resources/org/jenkinsci/plugins/jiraext/view/UpdateField/config.jelly
jira-integration-plugin/src/main/webapp/css/sync-with-jira.css
metrics-plugin/src/main/resources/jenkins/metrics/api/MetricsAccessKey/resource.css
qtest-plugin/src/main/resources/com/qasymphony/ci/plugin/action/PushingResultAction/config.jelly
qtest-plugin/src/main/resources/com/qasymphony/ci/plugin/action/SubmitJUnitStep/config.jelly
release-plugin/src/main/resources/hudson/plugins/release/dashboard/RecentReleasesPortlet/main.jelly
synopsys-coverity-plugin/src/main/resources/com/synopsys/integration/jenkins/coverity/extensions/buildstep/CoverityBuildStep/config.jelly
synopsys-coverity-plugin/src/main/resources/com/synopsys/integration/jenkins/coverity/extensions/pipeline/CheckForIssuesStep/config.jelly
synopsys-coverity-plugin/src/main/resources/com/synopsys/integration/jenkins/coverity/extensions/wrap/CoverityEnvironmentWrapper/config.jelly

Hopefully we can rather remove this rather than keeping it, but I could accept keeping it if we have to.

[batmat]

~1 month with no complaints

OTOH, this change was already released on weeklies only. Aren't these users a special profile? In a ideal world with no time limits/constrains, we would have shipped the change of the default value to an LTS release, isn't it?
And then if there there's no negative feedback for ~1 month, I would definitely agree with this stance.

WDYT?

[timja]

~1 month with no complaints

OTOH, this change was already released on weeklies only. Aren't these users a special profile?

Generally we get feedback pretty quickly if something is broken in weeklies. I don't expect delaying much longer to add more value but not in a big rush.

Most of the code here hopefully is separate enough to not conflict

[basil]

While working on the Jakarta EE 9 project, I noticed that a big wave of users upgraded to the latest weekly and reported issues, and then no issues showed up for a while until a second big wave of users upgraded to the latest LTS and reported issues. So I agree with Baptiste that there are a few profiles of users and that we don't necessarily get the full picture of user feedback until LTS ships.

I also agree with Tim that the risk is not too high with this removal. With regard to CSS, there might be a few visual regressions that can and should be fixed, but at least the functionality would still work. With regard to JavaScript, breakage would be more serious, but we have found relatively few plugins in the ecosystem that still have YUI JavaScript, and even fewer that are highly popular. My impression is that the same pattern was found in CloudBees proprietary plugins as well.

If we are still concerned about breakage, it might be possible to split the CSS and JavaScript removal into two separate phases/PRs, but even that seems likely overkill to me and I am mostly mentioning the idea for completeness.

[A1exKH]

@timja LGTM.

[daniel-beck]

would have shipped the change of the default value to an LTS release, isn't it?

The upcoming LTS line (looks like it'll be 2.492.x) will have YUI disabled by default, giving plugins 3 months to fix forward any newly discovered issues, while allowing affected installs to re-enable it. IMO it's unlikely it'll be so bad that we'd consider leaving YUI in core, and if it is, we can always revert this PR.

[daniel-beck]

Code changes look reasonable. I also reviewed leftover yui mentions and nothing looks like it needs addressing now.

[basil]

Once this is fully tested in ATH and PCT, this looks ready to me from an open-source Jenkins perspective. I will approve this PR once it is labelled as passing ATH and PCT.

I am not able to comment with great accuracy on whether CloudBees is quite ready for this in weekly releases, but my impression from a distance is that CloudBees is likely close to being ready for this. I will let others (@MarkEWaite? @scherler? someone else?) leave their thoughts about timing if necessary.