The test runner has started to fail for https://www.drupal.org/project/domain. The project has to setup custom subdomains in order to run tests. We had it working on 30 March, but now the same tests fail.
We have not made changes to the test configuration or core module code in that time.
https://www.drupal.org/pift-ci-job/1632512
The failures are all cURL errors related to subdomain handling. For example:
1) Drupal\Tests\domain\Functional\Views\ActiveDomainDefaultArgumentTest::testActiveDomainDefaultArgument
GuzzleHttp\Exception\ConnectException: cURL error 6: Could not resolve host: one.php-apache-jenkins-drupal-contrib-189314 (see http://curl.haxx.se/libcurl/c/libcurl-errors.html)We handle subdomains using a custom script, which seems to be firing normally as part of the build:
16:38:58 Container command.
16:38:58 /bin/bash -c "cd ${SOURCE_DIR}/modules/contrib/domain && chmod +x ./define_subdomains.sh && ./define_subdomains.sh"I really have no idea how to debug this issue.
Comments
Comment #2
drummI’m not sure if either of these ideas will really lead to resolving the issue, but they might help.
I recommend putting
set -xafter#!/bin/bashin shell scripts, like https://git.drupalcode.org/project/infrastructure/-/blob/master/live/gen.... This will show the commands being run by the script in the console output. (set -uexalso exits the script when using a variable that isn’t initialized or if any command has a non-zero exit status.)A
cat /etc/hostsat the end to double check the hosts were written couldn’t hurt too.example.comis a real domain. Usingexample.localmight provide better errors if thehostsfile isn’t properly overriding the host.Comment #3
agentrickardOK, I updated the script.
Comment #4
agentrickardThat seems to pinpoint an issue with the parsing of the directory.
Trying
Comment #5
agentrickardSo the problem is that we are no longer picking up the container name from the ${SOURCE_DIR} variable.
What environment variables do we have that can tell us the name of the container?
In this case, for instance, it is
jenkins-drupal8-contrib-patches-33134Perhaps SOURCE_DIR ?
Comment #6
agentrickardWell, I tried both SOURCE_DIR and PROJECT_DIR, and neither returns the name of the container.
Comment #7
agentrickardThis seems to be related to changes made by #3119432: The variable ${PROJECT_DIR} is not set correctly.
In that patch for drupal_ci_testbot, SOURCE_DIR and PROJECT_DIR are now both mapped to the root path inside the container? I need the path of the container.
SOURCE_DIR is now /var/www/html
PROJECT_DIR is now /var/www/html/modules/contrib/domain
But PROJECT DIR used to be something like var/lib/drupalci/workspace/jenkins-drupal8_contrib_patches-33134/source
The patch commit definitely fits within my timeline of “this was working and now it is not”
Comment #8
agentrickardWe tried using
hostnamebut that does not return the value we want.https://dispatcher.drupalci.org/job/drupal8_contrib_patches/33173/console
Returns
The workspace in this case is
jenkins-drupal8_contrib_patches-33173Comment #9
agentrickardDue to the changes from the other commit, I'm going to mark this as a bug (regression).
I suspect that we may need another system variable -- or someone just needs to document what that variable currently is and how it can be accessed.
Right now we only have PROJECT_DIR and SOURCE_DIR. It looks like we also need CONTAINER_DIR or CONTAINER_NAME.
Comment #10
MixologicThe PROJECT_DIR was always intended to be the directory of the project _inside_ the container, so that was a bug that we fixed.
When I fixed it, I checked all of the custom drupalci.yml files to see if anybody was using it/relying on that behavior, but I didnt see that there were scripts that use it.
Anyhow, I got drupalci back into an editbable state (some self tests were failing).
I will go ahead and add CONTAINER_NAME as a variable available within the container so you can use it like you were before (and dont have to rely on mining it out of a filesystem path).
Comment #11
MixologicThis was deployed, so you can remove all the parts of your script that sets CONTAINER_NAME, and just use it outright and it should work (I tested locally, and all the domain tests pass)