[JENKINS-56109] Change Jenkins configuration UI from tables to divs

[jsoref]

See JENKINS-56109.

Initially discussed in #3859

Test this

• Quick-start: https://github.com/oleg-nenashev/jenkins-tabs-to-divs-config-migration-testenv
• Manual setup: docker run --rm -ti -p 8080:8080 -e ID=3895 jenkins/core-pr-tester

Screenshots

Configure

Configure mobile

Nested elements association

Configure pipeline

Configure freestyle

Current status:

Needs reviews, also see: https://groups.google.com/d/msg/jenkinsci-dev/MpJMqa1Yc9A/Vex1yix8AAAJ

Proposed changelog entries

• JENKINS-56109, Tables are no longer used for layout in forms

Submitter checklist

• JIRA issue is well described
• Changelog entry appropriate for the audience affected by the change (users or developer, depending on the change). Examples
  * Use the Internal: prefix if the change has no user-visible impact (API, test frameworks, etc.)
• Appropriate autotests or explanation to why this change has no tests
• UI Acceptance test / changes necessary
• For dependency updates: links to external changelogs and, if possible, full diffs

Desired reviewers

@daniel-beck

Notes:

List of plugins provided by Daniel Beck which have jelly files that contain <td but not <table, indicating a reliance on existing structures at least in config.jelly and global.jelly files https://gist.github.com/daniel-beck/ef4a6f38d78014343a0ef5e85285c4ac. These therefore make a good test case for these changes in core, as we don't want all plugins to start breaking.

[jsoref]

Oh, I can write up a JEP for this if requested....

[jvz]

I'm not so sure about what you did moving those field attributes down from f:entry into child elements. That should be supported by using <f:prepareDatabing/> to set up field from the parent tag.

[oleg-nenashev]

CC @recena who was voting for it a while ago

[daniel-beck]

Impact on plugins is unclear. I fear if we expect all f:entry/f:whatever pairs to be updates, we won't see reasonable benefits here for a long, long time 😦

[jsoref]

@jvz: oops, hazard of iterating between various attempts. Thanks, I've undone that.

[jsoref]

Oops. No. The reason I moved the field was because I wanted to move the help. I'm going to put this back. Otherwise the help is floating aimlessly above the checkbox and looks ugly.

[jsoref]

I'm going to make a couple of changes from what I have here:

1. Adding group boundaries
2. I think I'm going to move help to above things -- right now (this picture is from unpatched jenkins), the help revealer for a select dropdown can be virtually offscreen:
   
   It either needs to be right below its item, or right above it, not below an entire super-expanding-group.

[daniel-beck]

I provided @jsoref with https://gist.github.com/daniel-beck/ef4a6f38d78014343a0ef5e85285c4ac, a list of Jelly files in plugins that contain <td but not <table, indicating a reliance on existing structures at least in config.jelly and global.jelly files. These therefore make a good test case for these changes in core, as we don't want all plugins to start breaking.

[varyvol]

@jsoref could you please resolve the merge conflict?

@timja @daniel-beck @fqueiruga how do you see the current state for this change? Can it be moved forward?

[timja]

@varyvol

I've been waiting for releases from the above people.

matrix-auth is now sorted thanks DB

reminder, could these be released please:

jenkinsci/promoted-builds-plugin#149 <- merged unreleased <- @oleg-nenashev

scm-api now released

[timja]

scm-api now released, pending any blockers we are probably good to move forward on this, probably discuss at next ux-sig meeting? (although I'm away for it)

[batmat]

First thanks a lot Tim for this stellar work, it's really an important update to Jenkins.

While there has unquestionably been awesome efforts to test and fix things in advance, I am inclined to recommend we merge this PR just after the next LTS baseline selection. This way, we would get the maximum time of weekly battle-testing for this change before it can reach the next-next LTS baseline.

Concretely: given the next baseline selection is planned for Wed 21st of October, I would propose we prepare this PR so it's ready-for-merge and on-hold before the meeting.
Then on this 21st of October, we merge this.

WDYT?

[daniel-beck]

Agree with @batmat. TBH I'm really surprised that fairly minor PRs held this up for almost two months. Had I known these were the blocker, and not the 50 or so open issues in the Jira filter, I'd have made the time many weeks earlier to give this some more soaking time in weeklies.

[fqueiruga]

+1 to what @batmat said.

[oleg-nenashev]

Concretely: given the next baseline selection is planned for Wed 21st of October, I would propose we prepare this PR so it's ready-for-merge and on-hold before the meeting. Then on this 21st of October, we merge this.

Works for me. I would not mind if we do not wait until Oct 21 either. This story is pretty solid at the moment.

jenkinsci/promoted-builds-plugin#149 <- merged unreleased <- @oleg-nenashev

Releasing it now

[oleg-nenashev]

Released https://github.com/jenkinsci/promoted-builds-plugin/releases/tag/promoted-builds-3.6 . The code looks good to me. I have tested the last version with the Jenkins PR Tester, and I have not seen any issues. I am +1 for getting it released in the coming weeks, subject to a final discussion at the UX SIG.

[romenrg]

This is a great step to modernize the Jenkins UI from the technical standpoint. Big improvement. Thanks to everyone involved, specially to @jsoref and @timja ! ❤️

[oleg-nenashev]

Do we have a consensus about merging the change. We have the LTS baseline selection scheduled to the next week. IIUC it is missing the next LTS baseline

[timja]

UX sig meeting on wednesday

[timja]

Discussed at the UX sig meeting:

Agreed we will ship it in the next weekly after baseline selection completed, (most likely 2.263).

🎉 thanks everyone for all your reviews and testing

[batmat]

Seems like it's time to un-on-hold this one and merge?

[timja]

Seems like it's time to un-on-hold this one and merge?
🎉

This PR is now ready for merge, after ~24 hours, we will merge it if there's no negative feedback.

Thanks!