stage1/docker-php committed a significant refactoring a couple of weeks ago. This refactoring provides not only the original container and image manager, but also new exec, volume, network, and miscellaneous (i.e. all other) manager objects. This release also removes all of the "there is no stable version of docker-php" text from their documentation.
Assuming the implementation is complete, upgrading docker-php should help remove a lot of complexity within the DrupalCI codebase. That said, it is a major refactoring, and will require extensive testing.
Comments
Comment #2
mile23Related: #2656446: Evaluate composer.json needs
Our composer.json says:
Ping @Mixologic. :-)
Comment #3
jthorson commentedUpdated and changes pushed on the 2656480-upgrade-docker-php branch.
We'll need to ensure that the stream timeout patch from Ryan's branch doesn't sneak back in with this change ... but the new docker-php rewrite appears to be using much more recent packages (and all in all, is much nicer to work with once you're familiar with it!)
Comment #4
MixologicThis is a prime candidate for "make these changes after we have tests in place".
Otherwise we're also missing the actual change to the composer.json to make this use the updated lib.Edit: saw that was in the branch, just not this patch.
Comment #5
mile23The 'after we have tests' issue: #2544340: Make the tests pass
Comment #6
mile23#2544340: Make the tests pass is fixed, so un-postponing here.
Comment #7
jthorson commentedUnless you have feedback, resetting to the original issue status.
Comment #8
MixologicSo, lets get https://www.drupal.org/node/2676854 in (provided it works, I've only done the R part, not the T part of RTBC), and add tests that prove that docker works fine. Then we add this branch in and prove it still works fine and then we can √ this off the todo list.
Comment #9
jthorson commentedDoes #2676854-14: [meta] Write functional tests to prevent regressions satisfy your need for a docker test first?
Going from stage1/docker-php to docker-php/docker-php is a complete rewrite and restructuring of the library, along with completely different class structure and methods. Even right off the start, the very first Client::createWithEnv method we use has been renamed to Client::createFromEnv.
We can write tests against the old library, but the changes are such that very few of those tests will actually carry forward without needing a full rewrite. I'd go so far as to suggest that, other than AssertInstanceOf('ImageManager') and AssertInstanceOf('ContainerManager'), everything else will require a rewrite of the tests virtually from scratch. Once again, I can't see the value in writing new tests against the old codebase, when we're going to need to rewrite those tests ANYWAY when we move to the new. We're not gaining any efficiencies here ... we're just generating extra work on a project that's already falling further and further behind. (We've got 5 month old feature development still hanging around, languishing in the queue, waiting on reviews.)
Sorry that I don't agree with you here ... but building out a functional test with a fixed set of assumptions is no different than manually executing a functional test with a fixed set of assumptions. Sure, it would be great to automate it, make it reuseable, and make it repeatable ... but writing those tests now (and rewriting them to the new docker-php API later) does not give any greater test coverage than the manual execution that I've already ran this stuff through - I simply don't see the extra value in holding back this work for weeks to wait for in-code testing, just to save a few hours of manual testing which has already been performed. And the best we can do right now is functional testing, until the code cleanup and decoupling which is waiting in the queue has actually been committed ... I'd rather we spend that effort on developing unit tests.
Unfortunately, I also recognize that I'm fighting against strongly held emotional convictions regarding purity of process, based on belief and opinion ... which is a battle that is virtually impossible to win using logical judgements based on fact. But if you look at the pros and cons of postponing this on the grounds of needing test coverage, it becomes pretty clear that we're creating unnecessary work while stifling innovation ... and neither of those does us any favours, here.
Comment #11
jthorson commentedMile23: I got a bunch of the tests converted ... can I get you to take a look at the two tests which are still failing on this branch?
Comment #12
mile23Sure. Will poke around.
Comment #13
mile23So after a ton of rebasing from dev and trying to make things work I get this:
Pushed rebased branch.
Comment #14
mile23Please don't ask me to work on a branch and then push changes before I'm unassigned.
Thanks.
Comment #15
jthorson commentedWhy did it need rebasing?
Comment #16
mile23Comment #17
jthorson commentedNo idea what you're talking about. I haven't touched the branch. Did you forget to pull?
Comment #18
mile23Nope.
Did you forget to pull dev before you merged it? :-)
Comment #19
jthorson commentedIf you're getting that error, you rebased my work out of the branch.
Comment #20
jthorson commentedLast dev commit: Friday
Branch Merge: Saturday
My last commit: Sunday at 11:59
My push: Sunday at 12:03
My ask for help: Sunday at 12:04
I'm still not sure what happened there ...
Comment #21
mile23OK, so one
git branch -D/git checkout -blater....Comment #22
jthorson commentedLocally, I've got it running phpunit without Fatals, throwing fails on FetchTest and ContainerCommandTest.
Comment #23
jthorson commentedAh ... cgit not reflecting the push!
Comment #24
jthorson commentedIRC?
Comment #25
mile23PullCommandTest says this:
Replicating the test in the CLI I see this:
So that tells me that whatever changes were made here don't throw an exception or notify you that the container doesn't exist.
Does the new library throw a helpful exception we are inadvertently catching, or give us some other way to check whether there was a fail?
Comment #26
mile23Comment #27
jthorson commentedIt used to throw an exception ... now it returns chunk-encoded json. I'm not sure how to go about dealing with that.
The ContainerTestCommand test is a little closer to working (i.e. probably more debuggable) ... I was thinking someone with more experience might be understand what it's complaining about, there.
Thanks!
Comment #28
jthorson commentedCurrently blocked on errors in docker-php. Needs resolution of:
https://github.com/docker-php/docker-php/issues/176
or
https://github.com/docker-php/docker-php/issues/180
Comment #29
MixologicComment #30
MixologicComment #32
mile23Tests pass, except for
DrupalCI\Tests\Plugin\BuildSteps\generic\ContainerCommandTest, which has been marked as incomplete.This change causes
./drupalci initto output super-fugly status messages like this: (It still works, just looks bad.)In IRC @Mixologic says the overall goal is to move towards docker compose, which means
./drupalci initis essentially deprecated in favor ofdocker pull.Since we need a test of the behavior of
ContainerCommand, this is still 'needs work.'Still not quite convinced about the
drupalci initweird text, but it still works for now.I'll write a test to cover
ContainerCommand.Comment #34
mile23OK, so here's what I did to
ContainerCommandTest:ClassName::classpattern for mock building.with()parameters.This means that we're exercising the code in
ContainerCommand::run(). We should follow-up with an issue to refactor some of theseforeach()loops into separate methods and then we can successfully unit test with goals in mind.Comment #35
MixologicAll right, looked at the test, looked at everything else, and we've got new docker-php. Goods. so now we can php7, and we can start in on docker compose stuff. Merged into dev.
Comment #36
mile23