| [15:40:03] | <mstenta[m]> | symbioquine: just saw your sans-xdebug test |
| [15:40:08] | <mstenta[m]> | that's a big improvement! |
| [15:40:26] | <symbioquine[m]> | Yeah |
| [15:40:54] | <symbioquine[m]> | I'll try to test the strategy you were describing with swapping the containers this evening :) |
| [15:41:16] | <mstenta[m]> | Cool! I hope that is as simple as it seems in my head haha |
| [15:41:25] | <symbioquine[m]> | Also posted to https://www.drupal.org/project/farm/issues/3183682 |
| [15:41:28] | <mstenta[m]> | I'm also curious if a similar approach can be used locally |
| [15:41:38] | <mstenta[m]> | Oh yes saw that too - just reading it |
| [15:42:24] | <mstenta[m]> | Awesome! |
| [15:42:35] | <symbioquine[m]> | <mstenta[m] "I'm also curious if a similar ap"> I'd imagine that would just imply a documentation update. Should be very fast since one image is build on the other, the prod image layers should already have been downloaded... |
| [15:42:47] | <mstenta[m]> | Yea I think so |
| [15:42:54] | <symbioquine[m]> | Obviously, we have to prove it works reliably first :) |
| [15:42:58] | <mstenta[m]> | Yea |
| [15:43:07] | <mstenta[m]> | Trying to think through what the local workflow would be... |
| [15:43:59] | <mstenta[m]> | (start with dev image, that's what you use normally, but when you want to test... can a standalone container image be run at the same time while the other two are, and just mount in the same directory? |
| [15:44:12] | <symbioquine[m]> | yep, I think so |
| [15:44:16] | <mstenta[m]> | or do you have to stop the running dev container, and then run your tests |
| [15:44:32] | <mstenta[m]> | cool - then it would just be a matter of crafting the right `docker run` command i think? |
| [15:44:32] | <symbioquine[m]> | I wouldn't think that would be necessary |
| [15:44:56] | <mstenta[m]> | on that note, i've been using some bash aliases to make things easier |
| [15:45:18] | <mstenta[m]> | eg: `fdrush` == `sudo docker exec -it -u www-data farmos_www_1 vendor/bin/drush` |
| [15:45:29] | <symbioquine[m]> | It's pretty common to have shared mounts for cases like one image refreshing certificates used by another |
| [15:45:34] | <mstenta[m]> | `fcode` == `sudo docker exec -it -u www-data farmos_www_1 vendor/bin/phpcs /opt/drupal/web/profiles/farm` |
| [15:45:46] | <mstenta[m]> | `ftest` == `sudo docker exec -it -u www-data farmos_www_1 vendor/bin/phpunit --verbose --debug --group farm` |
| [15:46:13] | <mstenta[m]> | ah yea that makes sense - i actually do that already for let's encrypt certs come to think of it :-) |
| [15:46:49] | <symbioquine[m]> | I think the main thing would just be making sure they can both access the DB and aren't trying to expose the same ports on the host machine. |
| [15:47:00] | <mstenta[m]> | yea |
| [15:47:22] | <mstenta[m]> | one thing to think about: docker compose creates a network so the www and db containers can connect |
| [15:47:33] | <mstenta[m]> | if we then also `docker run` another container, it will need access to that network |
| [15:47:45] | <mstenta[m]> | i haven't done that before, but i imagine it's not too hard |
| [15:50:07] | <symbioquine[m]> | Maybe it would be cleaner to have the instructions describe adding another "test runner" container to the docker-compose.yml file and using `docker-compose exec` for starting the tests? |
| [15:51:43] | <mstenta[m]> | ah yea that's another idea!~ |
| [15:51:54] | <mstenta[m]> | the `docker-compose.development.yml` template could just include that |
| [15:52:13] | <mstenta[m]> | would it be running all the time, though? |
| [15:52:29] | <mstenta[m]> | i wonder if it could be turned off by default, and only started on demand |
| [15:52:30] | <symbioquine[m]> | Yeah, depends how expensive it is to keep that container running all the time :) |
| [15:53:11] | <mstenta[m]> | the `docker run` might be simpler |
| [15:53:41] | <mstenta[m]> | so... another thing to think about: it's possible to run tests on sqlite3 |
| [15:53:51] | <mstenta[m]> | without needing a db container |
| [15:54:02] | <mstenta[m]> | i think i got that to work early on, but haven't tried since |
| [15:54:16] | <mstenta[m]> | and i suppose there's an argument for keeping consistent and running tests on postrgresql |
| [15:54:20] | <symbioquine[m]> | <mstenta[m] "the `docker run` might be simple"> Depends how much shell magic / $() expressions it takes to get it onto the right network and have the right bind mount. |
| [15:54:28] | <mstenta[m]> | yup yup yup |
| [15:55:20] | <symbioquine[m]> | <mstenta[m] "and i suppose there's an argumen"> Might make sense to parameterize the test runner and test against all three (sqlite/mysql/postgresql) :) |
| [15:55:20] | <mstenta[m]> | https://docs.docker.com/engine/reference/commandline/run/#connect-a-cont... |
| [15:55:38] | <mstenta[m]> | whoa now you're taking it to the next level! ;-) |
| [15:55:50] | <mstenta[m]> | maybe we do that in github... not locally haha |
| [15:55:55] | <symbioquine[m]> | exactly |
| [15:56:17] | <symbioquine[m]> | Prove that all three work at checkin time, but devs can mostly work against whichever is fastest |
| [15:56:26] | <mstenta[m]> | microsoft is giving us those free cpu cycles ;-) |
| [15:56:40] | <mstenta[m]> | yea speed is most important locally |
| [15:56:50] | <mstenta[m]> | i generally only run individual tests locally |
| [15:56:55] | <symbioquine[m]> | with some "advanced instructions" for doing the full test when something breaks only on some of the DBs |
| [15:56:59] | <mstenta[m]> | and then push to github for the full test |
| [15:57:05] | <symbioquine[m]> | :) |
| [15:57:37] | <mstenta[m]> | i'm curious about drupal.org testing infrastructure too... but i say we stick to github for now |
| [15:57:44] | <mstenta[m]> | d.o infrastructure team has enough on their plate :-P |
| [15:58:15] | <mstenta[m]> | could be really useful with the new issue branches feature though (gitlab integration so you can create a branch that corresponds to a d.o issue)_ |
| [15:58:18] | <symbioquine[m]> | <mstenta[m] "and then push to github for the "> Do you just keep pushing to the same "2.x" branch on your personal fork or do you modify the workflow file to trigger from other branches? (I could look too I guess...) |
| [15:58:23] | <mstenta[m]> | (and just testing patches too) |
| [15:58:35] | <mstenta[m]> | oh yea i've done both |
| [15:58:59] | <mstenta[m]> | i had a `test2x` branch that was JUST a change to the workflow to trigger on `test2x` branch pushes, and i would rebase that on top of whatever i wanted to test |
| [15:59:12] | <mstenta[m]> | but lately i've been lazy and have just been using `2.x` directly to my fork :-) |
| [15:59:41] | <symbioquine[m]> | Maybe it would be good to actually check in a wild-card trigger (I think there's a way to do that) to be used for that case and document it? |
| [16:02:17] | <symbioquine[m]> | https://stackoverflow.com/a/57903434 |
| [16:03:46] | <symbioquine[m]> | ACTION sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/jsgcLHiUQHdUqumr... > |
| [16:04:06] | <symbioquine[m]> | ACTION sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/LGCvWEewlVvztisY... > |
| [16:07:46] | <mstenta[m]> | oh yea that could be nice |
| [16:11:11] | <mstenta[m]> | maybe just simply: `2x-**`? |
| [16:11:23] | <symbioquine[m]> | yeah |
| [16:34:13] | <mstenta[m]> | great postgis discussion in the forum :-) |
| [16:36:21] | <mstenta[m]> | speaking of geodata... i need to debug the KML geocoding :-( |
| [17:10:01] | <mstenta[m]> | ah ha! easy fix! |
| [17:10:18] | <mstenta[m]> | https://www.drupal.org/project/geocoder/issues/3181471#comment-13911278 |