- Issue created by @jonathan1055
- Merge request !257Issue #3475581 Update current variant to use W3C selenium driver → (Merged) created by jonathan1055
- Status changed to Postponed
7 months ago 2:21pm 19 September 2024 - 🇬🇧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
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.
- 🇬🇧United Kingdom jonathan1055
jonathan1055 → changed the visibility of the branch main to hidden.
- 🇬🇧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' - 🇪🇸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.
- 🇬🇧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. - 🇬🇧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/402046Re-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 - 🇬🇧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 detailsPHPUnit
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_LEGACYAs 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 theif
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. - 🇬🇧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 -- move the definition of the variables from .nightwatch-base into .composer-base, or
- move the definition of the variables from .nightwatch-base into hidden-variables.yml
- 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.
- Status changed to Needs review
14 days ago 11:47am 24 March 2025 - 🇬🇧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.
- 🇬🇧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.
- 🇬🇧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.
- 🇪🇸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.
- 🇬🇧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?
- 🇬🇧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. - 🇪🇸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.
-
fjgarlin →
committed 02cf5906 on main authored by
jonathan1055 →
Issue #3475581 by jonathan1055, fjgarlin: Update Nighwatch jobs to new...
-
fjgarlin →
committed 02cf5906 on main authored by
jonathan1055 →
- 🇬🇧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
I've opened ✨ Nightwatch tests have lost their colors Active