Skip to content

Conversation

@rmuit
Copy link
Contributor

@rmuit rmuit commented Mar 9, 2019

These are two followups to #3847 which are not super related, but I hope putting them in one PR turns out to be less work.

  1. I found out why bootstrapDrupalSiteValidate() is called a lot more lately (since Better bootstrap refactor #3820):
  • BootstrapManager::bootstrapMax() has a loop for each phase, in which it calls bootstrapValidate()
  • bootstrapValidate() only checks its $result_cache for the current target phase is filled, and if it is not, validates all phases from 0 up to this target phase again.

I'm going to just assume that was not intentional and that it can be fixed this way.

--

  1. It was suggested to add a test, to add against regressions with the --uri flag.

So here it is. I'm guessing a fairly simple addition to CoreTest::testOptionsUri() will do the trick, even though that means it's now used to test two slightly different things.

Note - I just assumed that the 'expected' URLs are the ones that are returned by 'drush status' at this moment. I'm not 100% sure if that's true; you're in a better position to judge:

--

If this PR (containing both commits) is applied to the commit from before #3847, the test for "--uri=test.uri/subpath" fails as expected.

@rmuit rmuit changed the title Undupe validate Don't call bootstrapValidate commands repeatedly, and add --uri tests Mar 9, 2019
fwrite($fp, '
$sites["test.uri"] = "dev";
$sites["test.uri.subpath"] = "stage";
');
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if I should have reverted sites.php after this test finishes... You're not using "test.uri" anywhere else apparently, because tests still succeed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't hurt to leave sites.php in place; you could even commit this to the git repository if you wanted. Optional.

@weitzman
Copy link
Member

I'm not sure about the test (someone else should review it), but the bootstrapValidate() change looks right to me. I'll merge just that part, unless @greg-1-anderson chimes in otherwise.

// Test whether a URI in a config file resolves correctly, and test
// various URI values for their expected Site URI and path.
$drush_config_file = Path::join($this->webrootSlashDrush(), 'drush.yml');
$test_uri = 'http://test.uri';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We still want to test with --uri=http://test.uri. Looks like you removed this test.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two answers, to make surer I'm not misinterpreting:

  • This test is still being done; it's just done as part of the loop.
  • This (the current/old test) isn't testing with --uri=http://test.uri; it's only writing "http://test.uri" to the config file and testing with --uri=OMIT on the commandline. It's slightly hard to see because of naming, that $options_with_uri is not the --uri option on the commandline. Which is also why I renamed the variables.

Copy link
Contributor Author

@rmuit rmuit Mar 11, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could add a new drush invocation that tests --uri on the commandline (not writing config fille), though. Either with only one flag, or with all of them as part of the loop.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll have to re-read it later in context, but I think that $options_with_uri does have the --uri option on the commandline. At least that was my impression.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I see now. Tests look good.

Copy link
Member

@greg-1-anderson greg-1-anderson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Basic changes to bootstrapping look right, but we want to continue to test with test.uri to make sure everything is still working. Make your sites.php test in addition to the tests that were there before. I don't think you even need to dynamically write sites.php; we could just add it to the sut and commit it, I think.

Copy link
Member

@greg-1-anderson greg-1-anderson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I misread the code earlier. Tests look good. +1 on merging the whole thing once the tests come back green again.

@rmuit rmuit force-pushed the undupe-validate branch from 73ebc2b to ae8ba8e Compare March 11, 2019 21:07
@rmuit
Copy link
Contributor Author

rmuit commented Mar 11, 2019

Pushed a 3rd commit moving the $sites configuration into sut/sites/example.sites.php as suggested... since that is the file which is copied.
Tests OK locally.

Commit can be deleted if it turns out that keeping example.sites.php pristine is a better idea.

@greg-1-anderson
Copy link
Member

I forgot that we overwrite sites.php with example.sites.php repeatedly. Modifying example.sites.php would be okay, but Drupal Scaffold is going to overwrite this on composer update. We could either revert the last commit as suggested, or stop Drupal Scaffold from updating example.sites.php. I don't think we need an up-to-date version of this file for the sut.

@greg-1-anderson greg-1-anderson added this to the drush9 milestone Mar 12, 2019
@greg-1-anderson
Copy link
Member

If we set extras.drupal-scaffold.excludes to sites/example.sites.php, then Drupal Scaffold would not overwrite the example.sites.php file.

@weitzman Do you have a preference about committing example.sites.php vs dynamically writing sites.php?

@weitzman
Copy link
Member

I dont have a preference.

@greg-1-anderson
Copy link
Member

I have a slight preference for committing static fixtures; I'll add the Drupal Scaffold exclude and merge in a little bit.

@greg-1-anderson
Copy link
Member

We are not using Drupal Scaffold at the moment, so this is good to go.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants