Test module deployment etc

[jgaehring]

It's been a while since #468 was closed, and apart from whatever things might have gotten out of alignment since then, I want to use this space to run down any other lingering questions need to be addressed before working out the best way to deploy, host, test and update field modules on farmOS instances out there in the wild.

So a few thoughts right off the bat:

1. Do we still want to add Field Kit and Field Modules to the set of standard modules that come with farmOS? When do we consider the Field Kit module itself (aka, farm_fieldkit) stable enough for that kind of inclusion, and what kind of staged roll-out can we do in between? Furthermore, what is the criteria for individual Field Modules (eg, farm_fieldkit_tasks) to be added to the farmOS standard installation?
2. Can we automate the way new module releases get deployed? We touched on this briefly with Publish packages and automate publication for installing in farmOS #497, but the main concern there was with publication, which we just wound up doing here for simplicity, but ideally we could have some kind of CI process so farmOS could update them automatically in production, whether they were part of the standard installation or not. I know there are things like Packagist out there and we discussed this before, but I'll need to refamiliarize myself with the options.
3. What are potential issues with long-term stability of the Field Module API, particularly with reference to Use api/field_module/field_module in updateFieldModules #480? We came up with some workarounds for that, but imo, they were extremely brittle, and there's nothing to prevent those kinds of issues cropping up again in the future.

Any of these could be one or more separate issues, but I thought it best to evaluate them together on the whole before splitting anything out, so we can triage a bit on what needs to be dealt with first.

[mstenta]

Great questions @jgaehring! This might be a good topic for one of the weekly dev calls. It would be great to catch up and get a sense of things together!

On a previous call we discussed the idea of setting up a dedicated instance for testing/feedback (perhaps field-kit-test.farmos.net, akin to asset-link-test.farmos.net) where we can install modules, and grant logins to anyone willing to do testing. That seems like an easy next step to me, and I'd be happy to host that on Farmier! Maybe we can discuss what that requires in terms of code deployments and make a plan, while discussing the bigger questions in parallel.

[jgaehring]

On a previous call we discussed the idea of setting up a dedicated instance for testing/feedback (perhaps field-kit-test.farmos.net, akin to asset-link-test.farmos.net) where we can install modules, and grant logins to anyone willing to do testing.

Yes! I was struggling to recall the details of this we discussed (I feel like we may have also discussed using @paul121's Tugboat integration?).

That seems like an easy next step to me, and I'd be happy to host that on Farmier!

That'd be so awesome! 🙏

Maybe we can discuss what that requires in terms of code deployments and make a plan, while discussing the bigger questions in parallel.

Totally. Should I sit in on the call this Thu? Still 12pm Eastern?

[mstenta]

This Thu is going to be focused on JSON schema stuff w/ Greg and others. Maybe the following one on 9/7?

[mstenta]

Update: We spun up a Field Kit testing instance! If anyone is interested in getting a login, ping @jgaehring or myself in the farmOS chat room.

[jgaehring]

Update: We spun up a Field Kit testing instance!

Awesome, thanks @mstenta! 🙌

If anyone is interested in getting a login, ping @jgaehring or myself

And yes, this is another great reason for this instance, for anyone interested in trying out field modules w/o installing them on their own instance, esp. while we're still trying to get out of alpha and through beta.

2. Can we automate the way new module releases get deployed?

We discussed this on the call, too, and in the Matrix chat later. @paul121 pointed out that we can put multiple Drupal modules in the same repo with a single composer.json. The more I think about it, the more I really like that idea, even if it means extracting these "standard" field kit modules into their own repository here on GitHub or on the Drupal GitLab. We've published all the JS tooling to npm already, precisely so that field modules don't have to be a part of the main FK repo in order to run the dev server or build scripts. Then it's a simple matter of publishing to Packagist, which will crawl the repository periodically for updates, or perhaps not even that if we make the repository a Drupal project. Meanwhile, all farmOS has to do is require the field modules package in its own composer.json, and as @mstenta pointed out on Matrix:

farm_fieldkit doesn't need to know about any of them explicity. each field module "declares" itself when its drupal module is enabled, and farm_fieldkit just takes all of those and serves them to Field Kit

Again, none of this automation stuff is for the near term, but it gives us a nice target as we work out ways to publish field modules and install them manually on the testing/staging server for now.

[bitfieldfarm]

Log in to test instance was ok, but I get
"Request failed with status code 405" when logging in to FieldKit

[mstenta]

@bitfieldfarm Thanks for reporting! I think that might be this issue I just opened: #526 - we can use that issue to follow up.