@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_!
Discussed this with @nod_ in Slack, and, of course he was right.
Adding an MR with the MIA files now.
hang on, yarn vendor-update was not run on 11.x, lots of new languages were added. So we're missing translation files
yarn build was run on 11.x here:
https://git.drupalcode.org/project/drupal/-/merge_requests/10190/diffs?c...
yarn build includes yarn vendor-update.
So I'm confused now, what files are missing and do they turn up when you do a yarn build on 11.x?
Do the turn up if you do a yarn vendor-update on 11.x?
If the first question is answered with a yes, I messed it up.
Anything else, I'm scratching my head.
Oops
Well, the bump in 10.5.x has surprisingly little, as in none at all, effect on the CSS files in there.
So it already landed in 11.1.x, so making an MR for 10.5.x and am pretty hopeful this can be backported to 10.4.x easily.
Personally I think we might wanna backport this to 11.1.x, 10.5.x and 10.4.x
(Oh, the joy off multiple active main branches...)
I'll put MRs up for all three of them and let y'all decide.
Thanks @nod, do we want to backport this down to other branches?
No, bad bot!
Well, that required a lot more elbow grease than I expected/needed, but the errors are gone.
Same happens here. I think it has something to do with the fact I mistakenly started with a $ $ yarn upgrade-interactive, ehich is more/only for yarn 4.x
Let's start with a new MR.
Assuming the word changes are either the file out of sync or maybe cspell updated their internal dictionaries?
The latter for sure, that's the main part of each new minor bump in cspell.
The first part: No clue, maybe, maybe not.
IMHO the output on GitLab is what matters, the grimy internal format to get there is less relevant.
The output on GitLab is advertised in its own repo as looking something like this:
Screenshot from repo
And in our own drupal CSS Linting job: https://git.drupalcode.org/issue/drupal-3487817/-/pipelines/340184/codeq...
Do we add test coverage for new features added?
AFAICT we never did with previous bumps. although the idea is not without its merits.
I fear however, if we did, we'd be about just finished with defining and implementing the tests when a new version comes out.
Anyway: n=1, mileage may vary, yada yada.
Postponed on the landing of
📌
stylelint-formatter-gitlab prevents updating stylelint
Active
since leon0399/stylelint-formatter-gitlab does not work with stylelint versions above 15.x.