| [19:49:38] | <paul121[m]> | Okay, after seeing this bug I'm motivated to add some tests that simply request all of our routes and asserts a 200 response: https://github.com/farmOS/farmOS/pull/465 |
| [19:50:21] | <paul121[m]> | Ideally we could also use this to request the different page views of assets, logs, etc |
| [19:51:45] | <paul121[m]> | I imagine we could create a re-usable FunctionalTest base class for this... but then every test class that implements this will do a complete install, adding lots of test time |
| [19:52:27] | <paul121[m]> | If we could have a single functional test that performs all of these requests after one install that would be much better |
| [19:53:26] | <paul121[m]> | ideas? maybe it could just be a "profile" test that we manually update to include all the necessary modules + routes we want to test? |
| [19:53:50] | <paul121[m]> | s/ideas? maybe it could just be a "profile" test that we manually update to include all the necessary modules + routes we want to test?/ideas? maybe it could just be a "profile" test that we manually update to depend on all the necessary modules + and include routes we want to test?/ |
| [00:18:31] | <paul121[m]> | s/ideas? maybe it could just be a "profile" test that we manually update to include all the necessary modules + routes we want to test?/ideas? maybe it could just be a "profile" test that we manually update to depend on all the necessary modules + include routes we want to test?/ |
| [04:00:09] | * Anonymous[m]12 has quit (Quit: You have been kicked for being idle) |
| [04:40:17] | * farmBOT has joined #farmos |
| [07:01:12] | <mstenta[m]> | paul121: I like the idea of a single high-level test for this. Perhaps in https://github.com/farmOS/farmOS/tree/2.x/modules/core/test |
| [07:03:09] | <mstenta[m]> | Whereas all other tests are generally unit tests (for specific pieces of code) or functional tests (for isolated functions), this could be focused on a very high-level general testing - with the main goal of catching errors that bubble up from stuff we might be missing with lower level tests. It can serve as a last-resort catch-all, so to speak, which would help to inform improvements that may be needed in the lower level tests. |
| [07:03:30] | <mstenta[m]> | s/functions/functionality/ |
| [07:04:34] | <mstenta[m]> | The challenge might be in creating a representative set of content to test against. Perhaps this is also where the `farm_demo` module would be useful? We've talked about that as a "contrib" module, but perhaps it should be included in core for this very reason. |
| [07:05:44] | <mstenta[m]> | I know jgaehring was very interested in setting that up for Field Kit testing too. Maybe it would be worth all of us teaming up and sketching something up real quick together? |
| [07:06:33] | <mstenta[m]> | Then, this high-level test could essentially just be an array of URLs to iterate over and test for 200 responses, with a dependency on `farm_demo` |
| [08:16:49] | <mstenta[m]> | Should we try to get farmOS onto PHP 8 and make that the minimum version requirement before beta? |
| [08:16:56] | <mstenta[m]> | https://www.drupal.org/project/farm/issues/3186530 |
| [08:18:11] | <mstenta[m]> | GEOS support might be the only blocker: https://git.osgeo.org/gitea/geos/php-geos/issues/26 |
| [08:18:18] | <mstenta[m]> | https://www.drupal.org/project/farm/issues/3186477 |
| [08:47:58] | <jgaehring[m]> | <mstenta[m]> "I know jgaehring was very..." <- oh yea, I was thinking I'd probably punt on this til after the holidays, since I don't strictly need it for FK beta, I don't think |
| [08:48:14] | <mstenta[m]> | oh definitely |
| [08:48:31] | <mstenta[m]> | we can add these high level tests after beta |
| [08:49:37] | <jgaehring[m]> | for ref: |
| [08:49:37] | <jgaehring[m]> | https://farmos.discourse.group/t/farmos-demo-data/999 |
| [08:50:16] | <jgaehring[m]> | (also, have we still not hit topic 1000 yet???) |
| [11:12:01] | <paul121[m]> | <mstenta[m]> "Should we try to get farmOS onto..." <- I know there is at least 1 outstanding issue for simple_oauth and PHP 8 (updated our issue to reference that) |
| [11:12:46] | <mstenta[m]> | oh ok - good to know |
| [11:13:01] | <paul121[m]> | Once concern I have with requiring PHP 8 is that it might limit what contrib modules are available to us... |
| [11:13:33] | <paul121[m]> | I've heard that Drupal 10 might have a PHP 8 requirement, and a release is scheduled 6 months from now (June 2022)? So maybe better to wait until then? |
| [11:13:35] | <mstenta[m]> | Mm that's a good point |
| [11:13:40] | <paul121[m]> | When it is "official" ? |
| [11:14:15] | <mstenta[m]> | Yea perhaps... I wonder if we would need to bump our major version to 3.x if we change our PHP minimum requirements after beta? |
| [11:14:18] | <mstenta[m]> | What do you think? |
| [11:14:29] | <mstenta[m]> | PHP 7.4 is already EOL - with security releases until next Nov |
| [11:14:41] | <paul121[m]> | yeah good question, not sure |
| [11:14:50] | <mstenta[m]> | well what about this: |
| [11:15:27] | <mstenta[m]> | what if we just update our installation docs to say something like "PHP 7.4+ but PHP 8 will be required soon" or something to that effect |
| [11:15:46] | <mstenta[m]> | basically: can we set expectations ahead of time, so that we can do it in a minor version? |
| [11:16:06] | <mstenta[m]> | is there a patch for simple_oauth available? |
| [11:16:37] | <mstenta[m]> | if we can "officially" move to PHP 8 now, it wouldn't necessarily prevent others from using contrib |
| [11:16:57] | <mstenta[m]> | the question of what version is packaged in Docker could be separate perhaps |
| [11:17:40] | <paul121[m]> | mstenta[m]: it looks like there is a MR on that issue from the maintainer. But tests aren't running. Simple oauth is in the middle of a fairly big cleanup of dependencies and some other bugs. It's all somewhat tied together |
| [11:17:41] | <mstenta[m]> | eg: |
| [11:17:41] | <mstenta[m]> | 1) patch simple_oauth and test everything to make sure php 8 *works* |
| [11:17:42] | <mstenta[m]> | 2) change our docs to say "Requires PHP 8" (but still keep PHP 7.5 in docker for now) |
| [11:17:42] | <mstenta[m]> | 3) at some point in the future, update Docker to PHP 8 |
| [11:18:56] | <paul121[m]> | right, I was just thinking that, once we require PHP 8 it doesn't necessarily mean 7.5 won't work? |
| [11:19:13] | <mstenta[m]> | right |
| [11:19:17] | <paul121[m]> | as long as we (and contrib) don't use the latest features in v8? |
| [11:19:31] | <mstenta[m]> | 7.4 you mean (there is no 7.5) |
| [11:19:56] | <mstenta[m]> | yea |
| [11:20:00] | <paul121[m]> | yes - you mentioned 7.5 above, I wasn't sure :-) |
| [11:20:02] | <mstenta[m]> | and then once we move to D10 we can start using some of the nice PHP 8 stuff :-) |
| [11:20:06] | <mstenta[m]> | oh oops |
| [11:20:44] | <paul121[m]> | so what we're really saying is farmOS requires all of its dependencies to support PHP 8 |
| [11:20:53] | <paul121[m]> | so that later on we don't have to worry about that |
| [11:21:01] | <mstenta[m]> | yea |
| [11:21:12] | <mstenta[m]> | unofficially we still support 7.4+ |
| [11:21:30] | <mstenta[m]> | yea it's largely an expectation thing i think |
| [11:27:39] | <paul121[m]> | sounds good to me! |