[2.x] Failing updated deps test

@salvis, if you can fix this (or instruct me how to reproduce it so that I can submit a patch), can we then release a proper beta release of the 2.x branch? Or are there other outstanding issues? If so, we should probably open a separate "2.x beta release" issue where we track all the blockers.

This is caused by updating symfony/validator from 6.2.5 to 6.3.4, but not updating core to 10.1.x. Support for Symfony 6.3 has been added to Drupal 10.1 (see 📌 Update to Symfony 6.3 Fixed ).

This bug has been reported twice before in 💬 ExecutionContext::setNode() method not compatible with symfony/validator interface Closed: works as designed and 📌 PHP Fatal error: Declaration of Drupal\Core\TypedData\Validation\ExecutionContext Closed: duplicate but in both cases it got closed with the recommendation to either use `drupal/core-recommended` or to manage the whole set of Symfony dependencies manually.

In any case this is not a bug in ACL. I would recommend to change the automated test configuration → to not attempt to update the dependencies. We can maybe switch from PHP 8.1 & MySQL 5.7 updated deps, D10.0.7 to PHP 8.1 & MySQL 5.7, D10.0.7 (without "updated depts")?

SUPER helpful @pfrenssen, thank you!

@salvis, I think you are the only one with permissions to update/fix the test runner environments. If I can help in some way, please let me know.

HI if it's only a matter of depencies that differ for 10.0 to 10.1, wouldn't it be a solution to make a branch 2.x for 10.0 and 3.x for 10.1 with the same underlying code but not the same requirements ?

that's an interesting point.

ideally, it would be nice if the symfony dependency depended on the target druapl version. in fact, I thought this was kind of how composer worked naturally, but I might not be fully grasping the problem space here.

There is no reason for us to make a 3.x branch since this is not a bug on our side. There is literally nothing we can do inside the ACL module to fix this. This is a bug in Drupal core that is fixed in Drupal 10.0.10 (ref. 📌 Lock Drupal 10.0 on symfony/serializer and symfony/validator 6.2 Fixed ).

We had this failure since we ran a test with Drupal 10.0.7 which was still affected by this bug. The solution for us is to change our automated test configuration → .

hey @pfrenssen, thanks again for the thorough insight here.

you said "there is nothing we can do" but then you said we need to "change our automated test configuration".

You reasoning for updating the testing config sounds spot on to me. It sounds to me like the explicit step forward is the following, but please correct me if I am wrong:

@salvis need to update the 2.x-dev automated testing configuration → to change the following 3 (of 5) runners from :

PHP 8.1 & MySQL 5.7 updated deps, D10.0.7 2
PHP 8.2 & MySQL 8, D10.0.7
PHP 8.2 & sqlite-3.34, D10.0.7

to

PHP 8.1 & MySQL 5.7 updated deps, D10.1
PHP 8.2 & MySQL 8, D10.1
PHP 8.2 & sqlite-3.34, D10.1

The other two runners, which use PHP8.3 are failing on composer commands. I think that problem is unrelated to this issue. I am not sure if I should open a seperate issue for that problem, and both need to be resolved before a new 2.x alpha/beta/rc release, or if this is the only blocker at the moment. If you know the answer, by all means let me know, otherwise it may be a decision for @salvis.

This is caused by updating symfony/validator from 6.2.5 to 6.3.4, but not updating core to 10.1.x.

Thank you @pfrenssen for explaining, and thanks to the powers in charge for offering a test configuration that is guaranteed to fail...

Indeed, PHP 8.1 & MySQL 5.7, D10.0.7 is passing.

@xeM8VfDh: D10.0.7 is the current "Drupal 10 Stable Release", i.e. "The latest stable version of Drupal 10" — that's the one that we definitely need to run with. The version number is automatically adjusted to whatever is the stable release of the day.

The alternative is "Drupal 10 Development, currently 10.1.x", i.e. the bleeding edge "Drupal 10 development branch". Our test coverage is, sad to say, not very strong, and deprecated, too, and I think it's unlikely that we get hit by breaking D10 changes before anyone else does. Still, I've added a Weekly PHP 8.3-rc1 & pgsql-14.1, D10.1 test, bleeding edge for both D10 and PHP, as an early warning test, but Composer fails because a core dependency doesn't run with PHP 8.3. — Another test configuration that's guaranteed to fail for the time being, but it may come to pass at some point.

The other Composer fail is for PHP 8.3-rc1 & pgsql-14.1, D9.5. Obviously, this is my mistake: 2.x is supposed to run on D10, not on D9.5. I should never have created that configuration, and unfortunately, there seems to be no way to remove it (it has no link).

So, we should be set as far as the testbot goes.

sorry, I suppose I misunderstood the versioning bit.

@pfrenssen mentioned needing to get to Drupal 10.0.10. Are you saying D10.0.7 is "latest stable" and "10.0.10" is not eligible to be used? I have no idea how to find "stable release" information. All I see is this comprehensive list: https://www.drupal.org/project/drupal/releases →

in any regard, it sounds like you are saying "ignore the failing PHP8.3 test runners for now". so lets ignore that.

The main topic of this issue still remains, however... or does it? I ask because you said "we should be set as far as the testbot goes".

So I am still just generally confused.

It would be helpful to me if you can provide the following information:

1. is this issue (regarding failing dep tests) a "problem"? (yes/no)
2. if yes, are you clear about how to resolve the issue? (yes/no)
3. are there other issues blocking us from tagging a 2.x release? (if yes, a simple bulleted list of those tasks would be nice)

thanks :)

I don't know what you see under [Automated testing]. Here's what I see:

The configurations that have an link can be changed and even deleted, the other ones seem to be cast in stone.

I cannot remove the "PHP 8.3-rc1 & pgsql-14.1, D9.5 Composer require failure" test because it has no link. Kind of stupid, because 2.x is not intended to run with D9.5, but that's how it is. I should not have created that configuration...

The "PHP 8.3-rc1 & pgsql-14.1, D10.1 Composer require failure tested weekly" test does have an link, so that I could probably change or delete it. Actually, Drupal doesn't support PHP 8.3 at all according to https://www.drupal.org/docs/getting-started/system-requirements/php-requ... → , so it's no surprise that that test fails. We might just wonder why the configuration is offered. Chances are that it will start working some time in the future, so I'm leaving it as it is.

When I click , then I get this:

Here you see that I have no way of selecting 10.0.10.

I could re-run the red "PHP 8.1 & MySQL 5.7 updated deps, D10.0.7 2 pass, 2 fail", but as @pfrenssen pointed out, the failure is due to a bug in D10.0.7 Core. Because this test configuration doesn't appear in the list with the links, we can't change or delete it either. So, the best we can do is to ignore it. Based on @pfrenssen's input I've add the the "PHP 8.1 & MySQL 5.7, D10.0.7" test and this one passes. That's why I'm setting this issue to Fixed.

It would be helpful to me if you can provide the following information:

1. is this issue (regarding failing dep tests) a "problem"? (yes/no)
2. if yes, are you clear about how to resolve the issue? (yes/no)
3. are there other issues blocking us from tagging a 2.x release? (if yes, a simple bulleted list of those tasks would be nice)

So, NO, YES (=no further action required, we did what we can do), and NO. I created 2.0.0-beta1 two days ago.

It would have been nice to fix 🐛 "Invalid user specified." occurs for auto-complete user field if you don't select suggested username Needs work , but I didn't want to wait any longer.

Thanks! I wouldn't worry too much about the "updated dependencies" tests, since the ACL module doesn't have any Composer dependencies (except for Drupal core which is an implicit dependency). Any test failure caused by updated dependencies is not our responsibility to fix.

I wonder why the configuration still shows that 10.0.7 is the latest stable release instead of 10.0.11? I found the code that is responsible for generating this section (ref. https://git.drupalcode.org/project/project_issue_file_test/-/blob/7.x-3....) but it gets the list of core version by calling pift_get_core_labels() which gets them from the drupal.org database. So it looks like the database is not updated correctly when new core releases are issued. I created an issue to follow up on this: 🐛 Latest stable release for Drupal core is stuck on 10.0.7 Fixed .

Thank you, @pfrenssen, I guess they're abandoning Drupal CI as a measure to push GitLab CI...

thanks everyone! This does seem like something truly out of our hands thats full of confusing and misleading variables :)

Anywho, your alls analysis sounds right and reasonable to me.

THANKS for the 2.x beta @salvis, this is great!

Thanks to @pfrenssen 's 🐛 Latest stable release for Drupal core is stuck on 10.0.7 Fixed , Drupal CI was updated and the "updated deps" test passed: https://www.drupal.org/node/87985/qa →

I'm now changing all "The latest stable version of Drupal 10" tests to "Drupal 10 development branch", because according to @drumm, the former is not regularly maintained anymore.

Automatically closed - issue fixed for 2 weeks with no activity.