Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inline form element path #5926

Merged
merged 10 commits into from
Nov 25, 2021
Merged

Conversation

timja
Copy link
Member

@timja timja commented Nov 17, 2021

See jenkinsci/form-element-path-plugin#11 (comment)

This inlines form-element-path so that we can change it as part of UI re-work without having to update a separate test tool and get it released. It will also enable htmlunit testing with more stable selectors which will be nice.

It is enabled by:

  • default in unit tests
  • system property jenkins.formelementpath.FormElementPathPageDecorator.enabled=true *setting jenkins.formelementpath.FormElementPathPageDecorator.ENABLED = true` via script console.

ATH is setting system property with jenkinsci/acceptance-test-harness#712, all ATH tests are passing with this.

Plugin is EOLed in jenkinsci/form-element-path-plugin#12

For anyone who don't know what this is it's a plugin that provides an attribute on the DOM which is based on the 'path' to an attribute:

image

Proposed changelog entries

  • Add path to form elements giving stable selectors for UI testing.

Proposed upgrade guidelines

N/A

Submitter checklist

  • (If applicable) 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 must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

@timja timja added rfe For changelog: Minor enhancement. use `major-rfe` for changes to be highlighted developer Changes which impact plugin developers labels Nov 17, 2021
Copy link
Member

@jglick jglick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whether it should be enabled by default or with a system property

No strong opinion. Seems like it would be simpler overall to have this enabled unconditionally, so we could inline these additions into regular controls (probably generated server-side) rather than all these tricks with Behavior. If we are concerned about HTML bloat and do not want it on by default, then it could be gated by a system property, defaulting to Main.isUnitTest perhaps.

}

// expose this globally so that Selenium can call it
window.recomputeFormElementPath = applyAll;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will this blow up somehow if the plugin is also installed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I plan to bump the baseline of the plugin and empty it out initially so this shouldn’t really matter

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it wouldn't blow up anyway just last one to register would win

@timja
Copy link
Member Author

timja commented Nov 18, 2021

rather than all these tricks with Behavior

I've removed all the prototype.js code, we could inline this into hudson-behaviour.js#buildFormTree as well, but would rather keep it separate initially

applyAll();

// run this periodically to cope with DOM changes
window.setInterval(applyAll, 1000);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is what I'm most worried about having it on by default, every second recalculating the paths.

I tried removing it but its needed for repeatable elements to have the index added and re-calculated.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Jenkins already has runtime performance issues and periodic queries, I would avoid this as much as possible.

I'd suggest maybe registering this as a layout update callback (

var layoutUpdateCallback = {
). Most widgets already use it after adding new stuff (https://github.com/jenkinsci/jenkins/search?q=layoutUpdateCallback). Only repeatable is missing I think.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it's already registered a couple of lines down, I'll take a look at adding it to repeatable to see if it removes the need for this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should probably fix it for most plugins. Don't know if it's a problem that rogue plugins with custom widgets do not have this tbh

Copy link
Member

@jglick jglick Nov 18, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Jenkins already has runtime performance issues and periodic queries, I would avoid this as much as possible.

As in #5926 (review) you should either

  • Add the new HTML attributes or whatever unconditionally during Jelly generation, deleting all the JavaScript hacks, or at least as part of buildFormTree so it happens synchronously if and when a form is submitted.
  • Or disable all of this by default in production code.

Copy link
Member Author

@timja timja Nov 18, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will probably disable by default but also look to add repeatable to layout update callback so the timer bit can be removed.

The timer bit made debugging this code a pain.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe start with the current code copied-and-pasted from the plugin but disabled by default. That at least solves the immediate issue, we can gut the plugin, and simplify ATH to not try to load it.

Then as a follow-up look into whether the actual behavior can be simplified by inlining into lib/form/*.jelly and/or hudson-behavior.js.

@timja timja marked this pull request as draft November 18, 2021 14:19
@timja timja marked this pull request as ready for review November 19, 2021 21:41
@timja timja requested a review from jglick November 19, 2021 21:41
@timja
Copy link
Member Author

timja commented Nov 19, 2021

Review comments should be all addressed now.

a PR to adjust ATH:
jenkinsci/acceptance-test-harness#712

@timja
Copy link
Member Author

timja commented Nov 22, 2021

https://github.com/jenkinsci/acceptance-test-harness/pull/712/checks?check_run_id=4291377477 shows that something here isn't working, likely it's the removal of the run every second. I'll see if there's a fix otherwise I'll restore it since this is disabled by default now

@timja
Copy link
Member Author

timja commented Nov 23, 2021

The general case was failing because yui-button reworks the DOM, didn't really want to patch the library so I've just re-ran apply after 1 second.

Other case I noticed was pipeline code mirror, same workaround fixes that.

@timja
Copy link
Member Author

timja commented Nov 23, 2021

One plugin left failing atm: run_groovy – plugins.GroovyPluginTest

Will see if patchable otherwise will restore the run every second hack I guess

@timja timja mentioned this pull request Nov 24, 2021
10 tasks
@timja
Copy link
Member Author

timja commented Nov 24, 2021

All is passing now in ATH, @jtnord can you take a look please?

@timja timja requested review from Vlatombe and a team November 24, 2021 10:06
Copy link
Member

@jtnord jtnord left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Tim, this looks like a great improvement.

Would like a review by @Vlatombe before this merges - as the enabling via system property may cause some issues for some of our testing.

public class FormElementPathPageDecorator extends PageDecorator {

@SuppressFBWarnings("MS_SHOULD_BE_FINAL")
private static /*almost final */ boolean ENABLED = Main.isUnitTest ||
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should still be able to flip this switch via the installation of a plugin?
Currently we spin up some Jenkins' instance where we do not configure system properties (or doing so is hard) and the current flow is to install the form-element-path plugin without the use of the paths it provides. (e.g. auto provisioning in kubernetes)

@Vlatombe knows more about this area of the framework that we use internally.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's fine, we'll be able to provide the system property.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could also make it public as well

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as Vincent is ok with being able to provide it, we can keep it as it is for now (easier to open up, than restrict accesses later)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to turn this off by default, even in tests, at least until it can be rewritten to not rely on DOM listeners: jenkinsci/bom#746 (comment)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah that’s a shames :(

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#6004


@SuppressFBWarnings("MS_SHOULD_BE_FINAL")
private static /*almost final */ boolean ENABLED = Main.isUnitTest ||
SystemProperties.getBoolean(FormElementPathPageDecorator.class.getName() + ".enabled");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

possible future enhancement would be to also set this for RealJenkinsRule

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That should set isUnitTest IIRC.

}

/* JavaScript sometimes re-arranges the DOM and doesn't call layout callback
* known cases: YUI buttons, CodeMirror.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahhhh!!!! I wonder if this may well explain some issues we have with codemirror sections not being found in the ATH!

@timja
Copy link
Member Author

timja commented Nov 24, 2021

@jglick your comments should be addressed now if you want to take another look

@timja
Copy link
Member Author

timja commented Nov 24, 2021

or @Vlatombe you able to approve?

@timja timja added the ready-for-merge The PR is ready to go, and it will be merged soon if there is no negative feedback label Nov 24, 2021
@timja
Copy link
Member Author

timja commented Nov 24, 2021

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

Thanks!

@timja
Copy link
Member Author

timja commented Nov 24, 2021

PR to form-element-path to kill it off: jenkinsci/form-element-path-plugin#12

@timja timja merged commit b55eb6b into jenkinsci:master Nov 25, 2021
@timja timja deleted the inline-form-element-path branch November 25, 2021 08:45
@timja
Copy link
Member Author

timja commented Nov 26, 2021

Example using form element path to make an HtmlUnit test more stable / easier to maintain:
9281ae8

This test broke every time markup was touched a little bit

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
developer Changes which impact plugin developers ready-for-merge The PR is ready to go, and it will be merged soon if there is no negative feedback rfe For changelog: Minor enhancement. use `major-rfe` for changes to be highlighted
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants