Problem/Motivation
If the "bin-dir" setting is changed in "composer.json", then testing fails because "vendor/bin/" is hardcoded in a few places key to running tests.
This was being respected up until 11.3.x, probably because it was using the old `'core/scripts/drupal'` script, instead of the new `dr` one.
Steps to reproduce
- https://git.drupalcode.org/project/drupal/-/blob/main/core/tests/Drupal/...
- https://git.drupalcode.org/project/drupal/-/blob/main/core/tests/Drupal/...
We can see an example of running PHPUnit tests in here https://git.drupalcode.org/project/gitlab_templates_downstream/-/jobs/10...
Composer setting: https://git.drupalcode.org/project/gitlab_templates_downstream/-/blob/d1...
"config": {
"bin-dir": "custom-bin-folder/is/here"
}
Proposed resolution
Read the setting instead of hardcoding it.
Remaining tasks
MR
| Comment | File | Size | Author |
|---|
Issue fork drupal-3609757
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
fjgarlin commentedAdding related issue.
Comment #3
fjgarlin commentedThe same happens if "vendor-dir" is customized.
Comment #5
fjgarlin commentedReady for review.
* I used claude to help with the solution.
Comment #6
jonathan1055 commentedThis looks like a good solution, very comprehensive, covering all types of customized value. The test coverage looks good too.
I am surprised that core testing got this far with all the hard-coded instances you have found. Maybe not many sites have a custom bin-dir in real life?
Comment #7
fjgarlin commentedThis was tested in https://git.drupalcode.org/project/gitlab_templates/-/work_items/3572419... as well.
Comment #8
longwaveIs this useful outside of tests? Wondering if this is something we want to maintain in Utility, or whether it should just be a trait that can be included in tests that need it.
Comment #9
longwaveWe have
core/tests/Drupal/Tests/Composer/ComposerIntegrationTrait.phpwhich currently contains a single static method to find composer.json files in core, a bin dir finder could fit in there I think?I can't immediately think of a use case for this at runtime, so this will be easier to maintain in a test trait than it will be if we add it to the Utility component.
Comment #10
fjgarlin commentedI moved the method to the suggested file and changed the references to it. Needs review again.
Comment #11
jonathan1055 commentedHere is an example of the problem, in the d11-recipe branch of Gitlab Templates Downstream. Both the Drupal CMS and the current and future PHPUnit jobs fail with
Could not open input file: vendor/bin/drhttps://git.drupalcode.org/project/gitlab_templates_downstream/-/pipelin...
The tests use this change and I have re-run the pipeline following the work done in #10. The PHPUnit jobs still pass with the MR.
https://git.drupalcode.org/project/gitlab_templates_downstream/-/pipelin...
Next, I'm trying to patch the Drupal CMS job.
Comment #12
jonathan1055 commentedWith the Drupal CMS job patched too, that job ends green.
https://git.drupalcode.org/project/gitlab_templates_downstream/-/pipelin...
So this indicates that MR16277 is doing the right thing for
core/tests/Drupal/FunctionalTests/Core/Recipe/RecipeTestTrait.phpwhich is used on both of the contrib-facing tests.Comment #13
jonathan1055 commentedThe feedback from @longwave in #9 has been addressed, as the method is now moved into
ComposerIntegrationTrait. The changes look good, the internal test coverage shows that the various outputs are all covered, and my testing in a real recipe project shows that with this MR both the Drupal CMS test and the regular phpunit testing are fixed.So it looks like we can move it along to RTBC.
Comment #14
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. 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 #17
fjgarlin commentedToday's commit https://git.drupalcode.org/project/drupal/-/commit/854ccc02f134c81abf0b2... moved some logic into a different file. I rebased and applied exactly the same changes in the expected place.
No change in logic and code (other than the described), test results are exactly the same, so setting back to RTBC.
Comment #18
fjgarlin commentedNote: i also move the test to a folder where there is a similar test. The current location of the test file made it be the only test in that folder, which was full of traits. I'm happy to revert the last commit, but I thought it made sense.
Comment #22
longwaveNeeded some minor fixup after the directory move but I think that's ok. Also didn't backport cleanly because of the baseline diff, but I think I fixed that in the cherry-pick instead of sending it back for a new MR.
Committed a8ea302 and pushed to main. Thanks!
Committed b265e03 and pushed to 11.x. Thanks!
Committed 3372497 and pushed to 11.4.x. Thanks!
Comment #25
jonathan1055 commentedThanks for merging, and for the backport to 11.4.x
I have just confirmed in the Gitlab Templates test branch that the "next" variants, using 11.4.x and 11.x, are fixed.