Update to new driver when D11 "current" uses Nightwatch 3

Created on 19 September 2024, 7 months ago

Problem/Motivation

In 📌 Update templates so 11.0 is the default/current branch RTBC we discovered that the new "current" core version, defined by gitlab templates variable CORE_SUPPORTED which is updated to 11.0.x-dev in that issue, still needs to use the legacy driver. As at 18 Sept the core version loaded for 11.0.x-dev is 11.0.5-dev and this uses Nightwatch 2, which is not compatible with the W3C Selenium driver.

"Next Minor" variants are defined by CORE_NEXT_MINOR which is set to 11.x-dev and this currently uses core version 11.0-dev which has Nightwatch 3 and therefore needs the new driver.

Note

This issue is a placeholder for future work, so that an issue number and MR number can be generated, for adding into @todo comments when working on MR242

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

📌 Task
Status

Active

Component

gitlab-ci

Created by

🇬🇧United Kingdom jonathan1055

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @jonathan1055
  • Status changed to Postponed 7 months ago
  • 🇬🇧United Kingdom jonathan1055

    Note - no work needs to be started on this issue until MR242 has been merged and 📌 Update templates so 11.0 is the default/current branch RTBC is complete

  • 🇬🇧United Kingdom jonathan1055

    Adding related issue

  • 🇬🇧United Kingdom jonathan1055

    Now that 📌 Update templates so 11.0 is the default/current branch RTBC is complete we can unpostpone this and start work. It will not be ready for merging yet, but we can at least investigate the timeline for when we can do it.

  • Pipeline finished with Success
    5 months ago
    Total: 111s
    #338863
  • 🇬🇧United Kingdom jonathan1055

    jonathan1055 changed the visibility of the branch main to hidden.

  • Pipeline finished with Success
    5 months ago
    #338884
  • 🇬🇧United Kingdom jonathan1055

    Pushed the inital removal and changes, but any testing on this will fail for 'current' because 11.0.7 still needs the legacy chrome browser.

  • 🇬🇧United Kingdom jonathan1055

    Postponed on 🐛 Service not known with OPT_IN_TEST_NEXT_MINOR Active because MR291 will change the way services are defined.

    Probably also postponed until core 11.1 is released and we update CORE_STABLE to '11.1.0'

  • Pipeline finished with Success
    4 months ago
    Total: 113s
    #361319
  • Pipeline finished with Success
    4 months ago
    Total: 50s
    #370037
  • 🇪🇸Spain fjgarlin

    Is this one still needed? We might have solved it already, so if that's the case let's close it.

  • 🇬🇧United Kingdom jonathan1055

    Maybe, I've forgotten the details so will check back, and find out the Nightwatch versions now used in the variants.

    I will rebase MR257 anyway, and if there's nothing to be done, then the MR can be used to remove those @todo, etc.

  • Pipeline finished with Success
    3 months ago
    Total: 51s
    #401853
  • 🇬🇧United Kingdom jonathan1055

    OK I had to go back and fully refresh what we are doing here.

    .nightwatch-base has all the variables

    DRUPAL_TEST_WEBDRIVER_HOSTNAME_LEGACY: localhost
    DRUPAL_TEST_WEBDRIVER_HOSTNAME: selenium
    DRUPAL_TEST_WEBDRIVER_PORT_LEGACY: '9515'
    DRUPAL_TEST_WEBDRIVER_PORT: '4444'
    DRUPAL_TEST_WEBDRIVER_CHROME_ARGS: '--disable-dev-shm-usage --disable-gpu --headless'
    DRUPAL_TEST_WEBDRIVER_W3C: 'true'
    

    There is no plan to change this

    'current' nightwatch has

    # Use the legacy webdriver non-W3C-compliant settings
    # @todo In MR257 remove these three webdriver variables from here, and add
    # them into 'nightwatch (previous major)'
    DRUPAL_TEST_WEBDRIVER_HOSTNAME: $DRUPAL_TEST_WEBDRIVER_HOSTNAME_LEGACY
    DRUPAL_TEST_WEBDRIVER_PORT: $DRUPAL_TEST_WEBDRIVER_PORT_LEGACY
    DRUPAL_TEST_WEBDRIVER_W3C: 'false'
    

    because when 'current' was 11.0.n we needed to use the old values

    The nightwatch variant jobs extend nightwatch, not .nightwatch-base. The 'max PHP', 'previous minor' and 'previous major' do not modify anything from 'current' so they all have the legacy variables.

    next minor and next major both have

    # Set the driver variables to the W3C-compliant versions.
    # @todo In MR257 remove these three webdriver variables.
    DRUPAL_TEST_WEBDRIVER_HOSTNAME: !reference [.nightwatch-base, variables, DRUPAL_TEST_WEBDRIVER_HOSTNAME]
    DRUPAL_TEST_WEBDRIVER_PORT: !reference [.nightwatch-base, variables, DRUPAL_TEST_WEBDRIVER_PORT]
    DRUPAL_TEST_WEBDRIVER_W3C: !reference [.nightwatch-base, variables, DRUPAL_TEST_WEBDRIVER_W3C]
    

    This is because the two 'next' variants need the later versions of the variables, not the legacy values.

    I checked in this test to see what Nightwatch versions are loaded for the available varaints (ignore the failures, the project has no nightwatch tests, just a dummy file to trigger the jobs)

    • current core - core 11.1.1, Nightwatch 3.9.0
    • next minor - core 11.2-dev, Nightwatch 3.9.0
    • previous minor - core 11.0.8, Nightwatch 2.4.2
    • previous major - core 10.4.1, Nightwatch 2.4.2

    The changes done in MR257 is to have 'current', 'max php' and 'previous minor' all use the newer variables, and just 'previous major' use the legacy values. This is done by removing the overrides in 'current' and just adding them to 'previous major'. This also means that the two 'next' varaints can simply inherit from 'current' and no longer need their own overrides.

    But this is not actually correct, because 'previous minor' still needs the legacy variables as it uses version 2.4.2. That's a small change which I will do after I've run an actual test with this MR - I can use Decoupled Pages 📌 Testing gitlab_templates merge requests Active for that.

    Also the MR has some changes to the MINK_DRIVER_ARGS_WEBDRIVER variable in PHPUnit jobs, which will need to be checked.

  • Pipeline finished with Success
    3 months ago
    Total: 51s
    #402062
  • 🇬🇧United Kingdom jonathan1055

    As predicted, the Nightwatch 'previous minor' fails with this MR, but all other variants are OK
    https://git.drupalcode.org/issue/decoupled_pages-3422594/-/pipelines/402046

    Re-run with commit for 'previous minor' to use the legacy values, and they all pass
    https://git.drupalcode.org/issue/decoupled_pages-3422594/-/pipelines/402063

  • Pipeline finished with Success
    2 months ago
    Total: 51s
    #415988
  • Pipeline finished with Success
    about 2 months ago
    Total: 51s
    #429621
  • Pipeline finished with Success
    26 days ago
    Total: 60s
    #446034
  • 🇬🇧United Kingdom jonathan1055

    The changes made for the Nightwatch variants are all still valid, nothing needs to be done. I re-ran the Decoupled Pages MR8
    current 11.1.4, max php, next minor (11.2x-dev) all run Nightwatch 3.9.0
    previous minor (11.0.12) and previoius major (10.4.4) both use Nightwatch 2.4.2
    See this pipeline for MR8 for the details

    PHPUnit

    The changes in the PHPUnit jobs involve the variable MINK_DRIVER_ARGS_WEBDRIVER
    .test-variables has the two definitions MINK_DRIVER_ARGS_WEBDRIVER and MINK_DRIVER_ARGS_WEBDRIVER_LEGACY

    As it stands in the main branch, the phpunit 'current' job has the override to use the legacy variable
    MINK_DRIVER_ARGS_WEBDRIVER: $MINK_DRIVER_ARGS_WEBDRIVER_LEGACY
    which means that all the variants would use this value. However, the two 'next' variants contain
    MINK_DRIVER_ARGS_WEBDRIVER: !reference [.test-variables, variables, MINK_DRIVER_ARGS_WEBDRIVER]
    meaning that they use the new value not the legacy one.

    The existing work done in MR257 removes the legacy override in the 'current' phpunit job, but adds it back only for 'previous major'. Which means that 'previous minor 11.0 is using the new values. We need to check if this is right, because for Nightwatch the 'previous minor' still needed the legacy value.

  • 🇪🇸Spain fjgarlin

    I think MR257 looks good, but yeah, I totally agree that we if we react to the nightwatch version to set the variable one way or another that'd be amazing.

    We should probably try that here in this issue. I was thinking that we could use rules:variables (https://docs.gitlab.com/ci/yaml/#rulesvariables), but I'm not sure what the if conditions will be, so I'm happy for it to be calculated in the .composer-base job where we do all the other variables calculations.

  • Pipeline finished with Failed
    17 days ago
    #454061
  • Pipeline finished with Failed
    17 days ago
    #454062
  • Pipeline finished with Failed
    17 days ago
    Total: 148s
    #454065
  • Pipeline finished with Success
    17 days ago
    Total: 195s
    #454071
  • Pipeline finished with Success
    17 days ago
    Total: 324s
    #454131
  • Pipeline finished with Success
    17 days ago
    Total: 585s
    #454141
  • 🇬🇧United Kingdom jonathan1055

    I've pushed some changes, the detection of the Nightwatch version is working, but now I see why the variables are empty in build.env - thi si s because they are only defined in .nightwatch-base so are empty at the time the composer job is running. We have several ways forward -

    1. move the definition of the variables from .nightwatch-base into .composer-base, or
    2. move the definition of the variables from .nightwatch-base into hidden-variables.yml
    3. do the derivation of the variables in .nightwatch-base no .composer-base

    I think option 3 is better, as then the work is only done if the Nightwatch job is actually being run. It will sometimes be wasted effort if doing it always in Composer job.

  • 🇪🇸Spain fjgarlin

    Option 4: move the variables to .test-variables where we already have variables related to testing?

  • 🇪🇸Spain fjgarlin

    Scratch that, only used "too late".

    I think we can do option 3, but we need to keep BC in case somebody has given values there for their jobs. So we can "null" the values and then derive them in the job, in a way that it matches what we have now, but also do the derivation if the variable is empty, to keep any possible project-defined override.

  • Pipeline finished with Success
    16 days ago
    Total: 455s
    #454278
  • Pipeline finished with Success
    16 days ago
    Total: 193s
    #454331
  • Pipeline finished with Failed
    16 days ago
    Total: 51s
    #454385
  • Pipeline finished with Success
    16 days ago
    Total: 215s
    #454389
  • Status changed to Needs review 14 days ago
  • 🇬🇧United Kingdom jonathan1055

    I have made the changes to implement option 3. Keeping BC by defaulting the actual variables to blank, and only setting if non-blank. The legacy variables remain, as they may be referred to directly in customisations.

    The PHPUnit changes are better done in a separate issue, so I have removed them here. The work is similar, but testing separately is easier.

  • 🇪🇸Spain fjgarlin

    Code-wise it looks good and clean. I've triggered the decoupled pages pipeline here https://git.drupalcode.org/issue/gitlab_templates-3475581/-/pipelines/45...

    I see temporary code and I guess you might want to run additional tests, so marking NW based on that, but the code looks good and I am happy with the approach and the way we are keeping BC. Thanks for creating the separate PHPUnit issue, that'll make it easier here, and then there, to review and test.

  • Pipeline finished with Success
    14 days ago
    Total: 4281s
    #456150
  • 🇬🇧United Kingdom jonathan1055

    I have also triggered the downstream pipelines for d10-plus and d9-basic, both passed and the log shows what we expect. In particular, in d9-basic, the "current" variant automatically uses the legacy values, because it is running Drupal 10 not 11. The "previous major" is running Drupal 9.5 and an even earlier Nightwatch version 1.7, and it uses the same legacy values.
    https://git.drupalcode.org/project/gitlab_templates_downstream/-/pipelin...

    Here is a test of overriding the variables in Max PHP and here is the job showing that it worked. The legacy values were used, but the log message is confusing, so I'm going to improve that. The message is shown, then we do the checks for if the variable is empty, and may not make any changes. This needs to be better.

  • Pipeline finished with Success
    14 days ago
    Total: 665s
    #456307
  • 🇬🇧United Kingdom jonathan1055

    Pushed a change so the message is given only when the value was blank and is being set. In the normal job we get

    Nightwatch version is 3.9.0
    DRUPAL_TEST_WEBDRIVER_HOSTNAME set to 'selenium'
    DRUPAL_TEST_WEBDRIVER_PORT set to '4444'
    DRUPAL_TEST_WEBDRIVER_W3C set to 'true'

    But when overrides are used we get get the version line but not anything else - shown in this job

    Here is the updated documentation page

    I have removed the temporary code which skips the other downstream jobs, and this is ready for review.

  • Pipeline finished with Success
    13 days ago
    Total: 1429s
    #456395
  • 🇪🇸Spain fjgarlin

    I'd suggest changing the output slightly and always show it in the job, whether is derived or because it's set by the user.

    We could do something like:

    Nightwatch version is 3.9.0
    - Webdriver: selenium:4444 (w3c: true)
    

    Other than that small change I think it looks good to go. Setting to NW for that small change.

  • 🇬🇧United Kingdom jonathan1055

    That info is actually always shown later in the Nightwatch job - see https://git.drupalcode.org/project/gitlab_templates_downstream/-/jobs/47... But I like your concise output at the top so I will change that.

  • Pipeline finished with Success
    13 days ago
    Total: 226s
    #457134
  • 🇬🇧United Kingdom jonathan1055

    Done. I left in the echos but changed to say "Using default ..." and therefore the absence of these indicates that the values were preset in a custom job. d9-basic and d10-plus all pass. Here's an example

    Here is a test with override values

    Ready for review. Could you trigger the Decoupled Pages pipeline please?

  • 🇪🇸Spain fjgarlin

    Two really small nitpicks on the MR.

  • Pipeline finished with Success
    12 days ago
    Total: 51s
    #457298
  • 🇬🇧United Kingdom jonathan1055

    Thank you. Both are done.

    Did you notice that the older versions of Nightwatch (2.4 and 1.7) have output in colour, but version 3.9 is plain white. I don't know if there was a default of color 'on' which is now 'off'. I have just checked nightwatch --help and there does not appear to be any option to control this. So I guess we just go with it.

  • Pipeline finished with Success
    12 days ago
    #457304
  • 🇪🇸Spain fjgarlin

    Thanks for the changes! Marking RTBC.

    Good catch on the colors. Maybe an issue with the nighwatch code where it detects color support? (for example:https://github.com/nightwatchjs/nightwatch/issues/3601)

    This can be checked on another issue in any case.

  • Pipeline finished with Skipped
    12 days ago
    #457962
  • 🇪🇸Spain fjgarlin

    Merged. Thanks!

  • 🇬🇧United Kingdom jonathan1055

    Do you want an issue opened for the color support? I am not sure how to progress it, and I've got enough other open issues on the go at the moment. But if someone else, who knows more about Nightwatch than I do, would like to pick it up, that's fine with me.

  • 🇪🇸Spain fjgarlin

    We can defo open the issue so at least we know about it. It doesn't need to be top of the list and it can wait until other issues have been dealt with... and of course, anybody could pick it up in between.

  • 🇬🇧United Kingdom jonathan1055

    Fix typo in title

Production build 0.71.5 2024