IRC logs for #farmOS, 2020-11-21 (GMT)

[15:40:03]<mstenta[m]>symbioquine: just saw your sans-xdebug test
[15:40:08]<mstenta[m]>that's a big improvement!
[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
[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: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: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: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: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: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:37]<mstenta[m]>i'm curious about 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:03:46]<symbioquine[m]>ACTION sent a long message: < >
[16:04:06]<symbioquine[m]>ACTION sent a long message: < >
[16:07:46]<mstenta[m]>oh yea that could be nice
[16:11:11]<mstenta[m]>maybe just simply: `2x-**`?
[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!