Problem/Motivation
Build test, Command/GenerateThemeTest.php is failing on SQLite and 10.3.x. The test estContribStarterkitDevSnapshotWithGitNotInstalled
Drupal\BuildTests\Command\GenerateThemeTest::testContribStarterkitDevSnapshotWithGitNotInstalled
Fake git used by process.
Failed asserting that 0 matches expected 127.
core/tests/Drupal/BuildTests/Command/GenerateThemeTest.php:291
https://git.drupalcode.org/project/drupal/-/pipelines/215476/test_report...
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | 3458975-nr-bot.txt | 1.81 MB | needs-review-queue-bot |
Issue fork drupal-3458975
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
quietone commentedComment #3
quietone commentedComment #4
quietone commentedFWIW, this does pass locally.
Comment #5
quietone commentedI take that back, I made a mistake. It is failing locally.
Comment #6
pooja_sharma commentedAhh,, even I tried to replicate on local for me test pass on local , not sure may be missing any step at my end
Comment #9
longwaveThis appeared to break in the upgrade to Symfony 7.1, but not entirely sure why. Note also that this test only runs on SQLite anyway, it is skipped on other database engines.
What I think is happening is the updated
PATHenv var is not taking effect, and instead the currentPATHis being searched for thegitbinary. The attempt in the MR succeeds here locally but then fails later, let's see what happens on CI at least.Comment #10
longwaveActually I'm not sure how this test worked before, unless
gitwas not available in the environment perhaps?The fake
gitis set up and tested, but then the second Process object doesn't override$PATH, so how/why would it find the fakegitby that point?Comment #11
longwaveComment #12
longwaveOh I see, $env is passed into the second Process. But the first Process doesn't technically need it because it is executed from the context of PHP and PATH (or COLUMNS) don't come into play, so I pushed a simplification that works locally.
Comment #13
quietone commentedYes, it does look like it was the change to 7.1 that caused the problem. I started the tests on sqlite.
Comment #14
longwaveSo, this test *does* fail on all database drivers, but *only* if SQLite 3.45 is available. On Drupal CI, the MySQL and Postgres tests run in a different PHP container that only has SQLite 3.40, and so the tests are skipped.
However, for the purposes of this test at least, it seems it's not necessary to check the SQLite version - and I'm wondering if that's the case for any of the build tests.
Comment #15
longwaveMost tests run on php-8.3-apache:
but SQLite changes this:
And then you can see the difference by checking versions in the containers directly:
Comment #16
andypostFaced the same error but on Mysql and PHP 8.4alpha2 in #3427903-22: [META] Make Drupal 10/11 compatible with PHP 8.4
Comment #17
andypostFYI added changes from MR !8746 allowed to pass tests on 8.4!
EDIT fixed link
Comment #18
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #19
longwaveComment #20
andypostChanges looks ready for RTBC but somehow I can't trigger sqlite testing job
Comment #21
bradjones1I think maybe Dave needs to trigger it? "You are not authorized to trigger this manual job."
Comment #22
quietone commentedI started tests for SQLite
Comment #23
mondrakeI think this is Major if not Critical, since this issue has been systematically failing all SQLite test runs for quite some time.
Comment #24
mondrakeLooking at Issue Priority docs, https://www.drupal.org/docs/develop/issues/fields-and-other-parts-of-an-...
Comment #25
andypostI think it good to go to fix immediate bug and continue (for 11.x) with #3461006: Use Ubuntu images in all CI environments for core
Comment #30
catchCommitted/pushed to 11.x and cherry-picked back through to 10.3.x, thanks!
Comment #32
catch