Added a first draft for a CR.
Hmmm,
If I search core for "varchar" I get ~1200 results, so I would expect those to fail in the core GitLab CI, which they don't.
So that makes me think it's a GitLab (config of cspell-run) problem, and not a specific cspell version problem?
And as a side-note: This MR also seems to bump cspell from version "8.16.1" to version "8.17.1".
Perhaps by deleting the yarn.lock before doing a yarn install?
I tried this but also got shipwrecked on the Selenium session bit, probably some new config option we have to pass somewhere?
Oh, and all the resolutions we all love to hate in the package.json are there because of Nightwatch holding at 2.4.2.
If we get it higher, we can drop all of them AFAICT.
Two test-failures, one is a known random, the image one I haven't seen before myself, but I would find it _very_ weird if that could be cause by tuf.
Marking as RTBC.
MINIMUM_STABILITY should be set to 'stable' in core/tests/Drupal/BuildTests/Composer/Template/ComposerProjectTemplatesTest.php.
Not to sure we want to change the composer.json files.
I agree, basically by default, with @mondrake.
Adding the current errors to the baseline would, as already stated by @mondrake, flag any new ones that pop up.
If we added them to be ignored by default with the parameters: ignoreErrors: "magic" new ones would also be ignored without warning us and thus not give us the chance to fix them, or at the very least give it an attempt.
So I'm on #TeamMondrake for adding them to the baseline.
NW is probably the status for this now.
No clue either, but I'm officially calling it quits on trying to update any JS dependency.
It's far too tedious with rerolls, canary-in-coal-mine for broken HEADs and multiple branches.
I think we should put time in researching something like Renovate or whatever shiny stuff works on GitLab these days.
IMHO it shouldn't take the roughly 10-15hrs I've spent this time around.
This is by no means a rant against core committers, who can somehow juggle multiple branches almost perfectly, but for mere mortals like me, this is _very_ frustrating and something that looks like it can be achieved with automation far easier than a/this human banging its forehead on a keyboard :)
After:
$ yarn outdated --no-links
yarn outdated v1.22.22
info Color legend :
"<red>" : Major Update backward-incompatible updates
"<yellow>" : Minor Update backward-compatible features
"<green>" : Patch Update backward-compatible bug fixes
Package Current Wanted Latest Package Type
eslint 8.57.0 8.57.1 9.17.0 devDependencies
glob 10.3.5 10.3.5 11.0.0 devDependencies
jackspeak 2.1.1 2.1.1 4.0.2 resolutionDependencies
nightwatch 2.4.2 2.4.2 3.9.0 devDependencies
postcss 8.4.38 8.4.49 8.4.49 devDependencies
postcss-preset-env 9.5.11 9.6.0 10.1.2 devDependencies
semver 7.5.4 7.5.4 7.6.3 resolutionDependencies
shepherd.js 10.0.1 10.0.1 14.3.0 devDependencies
TBH I've ran out of steam for fancy diffs and linking issues for stuff that can't be done.
Instead here's the before:
$ yarn outdated
yarn outdated v1.22.22
info Color legend :
"<red>" : Major Update backward-incompatible updates
"<yellow>" : Minor Update backward-compatible features
"<green>" : Patch Update backward-compatible bug fixes
Package Current Wanted Latest Package Type URL
@floating-ui/dom 1.6.5 1.6.12 1.6.12 devDependencies https://floating-ui.com
chokidar 3.6.0 3.6.0 4.0.1 devDependencies https://github.com/paulmillr/chokidar
dotenv 16.4.5 16.4.7 16.4.7 devDependencies https://github.com/motdotla/dotenv#readme
eslint 8.57.0 8.57.1 9.17.0 devDependencies https://eslint.org
eslint-plugin-import 2.29.1 2.31.0 2.31.0 devDependencies https://github.com/import-js/eslint-plugin-import
eslint-plugin-no-jquery 3.0.2 3.1.0 3.1.0 devDependencies https://github.com/wikimedia/eslint-plugin-no-jquery#readme
eslint-plugin-prettier 5.1.3 5.2.1 5.2.1 devDependencies https://github.com/prettier/eslint-plugin-prettier#readme
eslint-plugin-yml 1.14.0 1.16.0 1.16.0 devDependencies https://ota-meshi.github.io/eslint-plugin-yml/
glob 10.3.5 10.3.5 11.0.0 devDependencies https://github.com/isaacs/node-glob#readme
jackspeak 2.1.1 2.1.1 4.0.2 resolutionDependencies https://github.com/isaacs/jackspeak#readme
jquery-ui 1.14.0 1.14.1 1.14.1 devDependencies https://jqueryui.com
jsdom 24.0.0 24.1.3 25.0.1 devDependencies https://github.com/jsdom/jsdom#readme
nightwatch 2.4.2 2.4.2 3.9.0 devDependencies https://nightwatchjs.org
postcss 8.4.38 8.4.49 8.4.49 devDependencies https://postcss.org/
postcss-preset-env 9.5.11 9.6.0 10.1.2 devDependencies https://github.com/csstools/postcss-plugins/tree/main/plugin-packs/postcss-preset-env#readme
prettier 3.2.5 3.4.2 3.4.2 devDependencies https://prettier.io
semver 7.5.4 7.5.4 7.6.3 resolutionDependencies https://github.com/npm/node-semver#readme
shepherd.js 10.0.1 10.0.1 14.3.0 devDependencies https://shepherdjs.dev
sortablejs 1.15.2 1.15.6 1.15.6 devDependencies https://github.com/SortableJS/Sortable#readme
terser 5.31.0 5.37.0 5.37.0 devDependencies https://terser.org
terser-webpack-plugin 5.3.10 5.3.11 5.3.11 devDependencies https://github.com/webpack-contrib/terser-webpack-plugin
tua-body-scroll-lock 1.5.0 1.5.3 1.5.3 devDependencies https://github.com/tuax/tua-body-scroll-lock#readme
underscore 1.13.6 1.13.7 1.13.7 devDependencies https://underscorejs.org
webpack 5.96.1 5.97.1 5.97.1 devDependencies https://github.com/webpack/webpack
They all we're needed to pass the stylelint job, see https://git.drupalcode.org/issue/drupal-3487817/-/pipelines/359246/codeq...
Nice,
The only failing test now is an annoying one, which always gets me.
In core/tests/PHPStan/composer.json the version of phpstan/phpstan should match the version that is in composer.json.
Thanks for the hard work @ptmkenny
The first two errors you mentioned are caused by there being text after the
So far example <code>core/tests/Drupal/Tests/Core/State/StateTest.php /**
* Tests both get() & delete() method.
*
* Here testing the key and value after deleting the key's value.
*
* @covers ::get
* @covers ::delete
*
* Ensure that deleting clears some static cache.
*/
So if we put that last line before the @covers ::get PHPStan should be much happier.
The missingType.generics are much harder to fix and we _could_ suppress them, so the behaviour on those would be the same as in PHPStan 1.x, with:
parameters:
ignoreErrors:
-
identifier: missingType.generics
https://github.com/phpstan/phpstan/blob/2.0.x/UPGRADING.md#removed-optio...
spokje → changed the visibility of the branch 3493141-bump-cspell-to to hidden.
Rebased
Reran $ yarn spellcheck:make-dict on a clean core checkout.
Thanks again @quietone!
@quietone, Crap I fell into my old nemisis' trap yet again: Running a dictionary rebuild on a non-clean core checkout.
Thanks for noticing, I'll fix that right away.
@smustgrave Are you sure? I see a fully green pipeline on this MR: https://git.drupalcode.org/project/drupal/-/pipelines/359531
@andypost You might want to do a rebase, there were some rollbacks after we've found out HEAD of 10.4/5.x was broken.
Thanks @salmonek, for both being a nice person and reporting back :)
Right some rollbacks later, and we have a green MR.
_tips hat_
@longwave, Ah, I seee, thanks for explaining.
We _could_ open an issue in their queue and wait for confirmation, we could test it ourselves or we could just steamroll ahead.
First option is probably going to taken longer than the window we have before 11.1.0 gets shipped, option #2 is for the nice people out there.
Sadly I'm not one of those, going to mark this RTBC to get this in 11(.1).x ASAP (10.4/5 seem to have a broken HEAD) and move one.
The ~12.000 install aren't going to jump to 11.1.0 immediately, so if things go wrong with the key, there's time to fix it.
This broken HEAD on 10.5.x and 10.4.x with a cheery:
$ vendor/bin/phpunit -c core core/modules/system/tests/src/Unit/Breadcrumbs/PathBasedBreadcrumbBuilderTest.php
PHPUnit 9.6.21 by Sebastian Bergmann and contributors.
Testing Drupal\Tests\system\Unit\Breadcrumbs\PathBasedBreadcrumbBuilderTest
........... 11 / 11 (100%)
Time: 00:00.257, Memory: 12.00 MB
OK (11 tests, 56 assertions)
Remaining direct deprecation notices (2)
2x: Since symfony/http-foundation 6.3: Calling "Symfony\Component\HttpFoundation\Request::create()" with an invalid URI is deprecated.
2x in PathBasedBreadcrumbBuilderTest::testBuildWithInvalidPath from Drupal\Tests\system\Unit\Breadcrumbs
Remaining indirect deprecation notices (1)
1x: Automatic conversion of false to array is deprecated
1x in PathBasedBreadcrumbBuilderTest::testBuildWithInvalidPath from Drupal\Tests\system\Unit\Breadcrumbs
Unsure why it works on 11.x with Symfony 7.2, where I would expect the deprecation throwing code would be removed, but it does.
As an added weirdness-bonus, the test fails, making the unit-test job fail on GitLab, but the specific error doesn't show up in the report.
I can only find it in the raw output of the unit-test job.
Code changes seem fine an GitLab loves them.
This has a new requirement for a license key. We can default it to "GPL" but https://www.drupal.org/project/ckeditor5_premium_features → also wants to set this so we should ensure that is still possible.
Not too sure if we're supposed to this this here or in the contrib queue for ckeditor5_premium_features ?
What have we learned:
1. Updating an MR on non-11.x in a branch made from 11.x many moons ago is a nightmare
2. Not-so-random-failures in 10.5.x tests that don't seem related to the changes in this MR. Dropped a few lines in Slack about this.
spokje → changed the visibility of the branch 3488005-11.x-bump-stylelint to hidden.
spokje → changed the visibility of the branch 3488005-10.5.x-bump-stylelint to active.
Ah, those bits, with the whole is(#yada .yada) were auto generated, I am even less a front end person than you are probably.
I could never come up with stuff like that.
But by all means, let experts look at it.
- Changes make sense
- Suppressions were added by request form @nod_ who knows "stuff" about front-end, so that should be fine.
- Tests are green
RTBC for me.
So the tests are passing when we move
php-tuf/composer-stager
to a dev dependency.
However, the test in \Drupal\BuildTests\Composer\Template\ComposerProjectTemplatesTest::testMinimumStabilityStrictness uses composer --working-dir=$root info --format=json to get all the dependencies from
This list also contains dev-dependencies, so it will still fail if we bump testMinimumStabilityStrictness to stable.
spokje → made their first commit to this issue’s fork.
Were these auto generated?
@smustgrave, I assume you're talking about the PCSS (and thus also the CSS) changes in this MR.
They're not auto-generated, but were manually changed to make this MR pass tests.
It seems I didn't push after the first commit which only bumped postcss and friends, so there's no test-results from that one, but that complained about @nest being deprecated, so I removed that from all PCSS-files and did a $yarn build:css.
That came back with errors (See https://git.drupalcode.org/issue/drupal-3487817/-/pipelines/350377/codeq...), which I manually corrected (and another $yarn build:css) in my third commit, after which all went green.
$ git checkout -b '3490163-11.x-bump-composer-dependencies' --track drupal-3490163/'3490163-11.x-bump-composer-dependencies'
error: invalid path 'core/modules/system/tests/modules/icon_test/icons/name_special_chars/FoO !?1:èç 2 "#3 B*;**a,ù$R|~¹&{[].svg'
Well that's me on a Windows git-bash based system out of the running for core work...
I've added the tracking issue, somebody needs to pick this up and/or also my JS-dependency updates.
spokje → changed the visibility of the branch 3490183-update-composer-dependencies to hidden.
spokje → created an issue.
Dependency php-tuf/composer-stager with stability RC does not meet minimum stability stable.
Unsure if this dependency is allowed to be RC, or flew in under the radar when MINIMUM_STABILITY was lowered to accommodate SF.
Otherwise things look fine.
Fail in tests seems like a random BlockCacheTest fail. RTBC-ing
$ composer-lock-diff --no-links
+------------------------+----------+----------+
| Production Changes | From | To |
+------------------------+----------+----------+
| pear/pear-core-minimal | v1.10.15 | v1.10.16 |
+------------------------+----------+----------+
+------------------------------+-------+-------+
| Dev Changes | From | To |
+------------------------------+-------+-------+
| composer/class-map-generator | 1.4.0 | 1.5.0 |
| php-http/guzzle7-adapter | 1.0.0 | 1.1.0 |
+------------------------------+-------+-------+
$ composer-lock-diff --no-links
+-------------------------+------------+------------+
| Production Changes | From | To |
+-------------------------+------------+------------+
| pear/pear-core-minimal | v1.10.15 | v1.10.16 |
| php-tuf/composer-stager | v2.0.0-rc5 | v2.0.0-rc6 |
+-------------------------+------------+------------+
+------------------------------+---------+---------+
| Dev Changes | From | To |
+------------------------------+---------+---------+
| composer/class-map-generator | 1.4.0 | 1.5.0 |
| composer/composer | 2.8.2 | 2.8.3 |
| composer/pcre | 3.3.1 | 3.3.2 |
| php-http/guzzle7-adapter | 1.0.0 | 1.1.0 |
| phpstan/phpstan | 1.12.10 | 1.12.11 |
| phpstan/phpstan-phpunit | 1.4.0 | 1.4.1 |
| squizlabs/php_codesniffer | 3.10.3 | 3.11.1 |
+------------------------------+---------+---------+
spokje → changed the visibility of the branch 3490163-update-composer-dependencies to hidden.
@longwave Can't reproduce that locally.
Also https://git.drupalcode.org/issue/drupal-3488005/-/jobs/3485149#L272 indicates that the same command, but with added frills like caching and custom formatters does, at the very returns and doesn't get stuck.
Tried to clarify the IS, since there seems to be a lot of misunderstanding of what we're trying to accomplish in this issue.
spokje → changed the visibility of the branch 3488005-10.5.x-bump-stylelint to hidden.
Unsure if I, as the creator of the original branches can RTBC, but since there's not much time left before 10.4.0-RC is shipped, I'm willing to bend the rules and RTBC-ed.
#yolo
Thanks @quietone.
Follow-up issue created: 📌 Link output of CSS eslinting on GitLab correctly Active
spokje → changed the visibility of the branch 3467309-stylelint-formatter-gitlab-prevents-updating to hidden.
Combo of multiple MRs and it isn't too clever when it comes to *.lock files IMHO, both composer.lock and yarn.lock.
Anyway, this issue was bumped and you noticed it because of the bot, so that's good enough for me :)
Why don't you help yourself to a nice cold glass of ST[Bleep!]U, needs-review-queue-bot?
Thanks @longwave, pulling the trigger
- Code changes makes sense (and are quite ingenious IMHO)
- Seems to work according to the "profiling" comments in here.
Would love to RTBC, the only thing keeping me from doing so is the last commit, which introduced the setting twig_sandbox_allowed_methods to overrule the predefined list of allowed methods.
I think if we introduce a new setting, a commented example should be in web/sites/default/default.settings.php with some comments about what it does.
Then again: n=1, your mileage/opinion may vary, yada yada
Needs rebasing, but I'll wait for some of the other sibling issues to land before doing so.
Otherwise we're entering rebase-ception land.
HEAD unbroken, rebased
Added missing files to the 10.5.x MR, but that branch seems to have a broken HEAD:
https://www.drupal.org/project/drupal/issues/3488179#comment-15863742
🐛
RecipeConfigurator::getIncludedRecipe() should statically cache recipe objects to avoid performance problems
Active
Looks like this broke HEAD of 10.5.x: https://git.drupalcode.org/project/drupal/-/pipelines/343235
In an unrelated MR elsewhere I'm also consistently hitting the exact same error
In InputConfigurator.php line 137:
Input values cannot be changed once they have been set.
recipe [-i|--input INPUT] [--] <path>
in both core/tests/Drupal/FunctionalTests/Core/Recipe/CoreRecipesTest.php and core/tests/Drupal/FunctionalTests/Core/Recipe/StandardRecipeTest.php.
Didn't check but I can imagine the same thing happening in 10.4.x?
Opened MR!10246 to add the missing JS files to 11.x, hoping that it's a 1-on-1 backport to 11.1.x.
I've changed my local, faulty .gitignore so this won't happen again.
All credits for finding out about this distaster-in-progress to @nod_!