The problem is that this demo config we never customized. The CI is not running its automated tests. It is just sitting there slowly rotting as the code gradually drifts away from default.
There is no point in having/maintaining duplicate copies of the same config. I think we should delete the config/demo project. Then we should be serious about maintaining config/default as a demo showcase of a simple “production ready” configuration demonstrating various best practices.
I agree that the demo config is only confusing things.
I believe that we need to have some configuration that covers all CHT features, and this configuration should be e2e tested, and I’m not sure this config should be default (as it may prove overwhelming and too arbitrary as an entry point for the application).
I think that at some point, we decided to make different configs when we added features that required changes, which is now why we have the covid-19 config - where the only additional feature that is turned on is to integrate with another android app: 6981 covid19 config (#7273) · medic/cht-core@311f81f · GitHub (I believe that this config has a custom form).
Yes! I love the idea of removing the demo config if it’s a near duplicate of default
To Diana’s point about a config that covers all the features, maybe we’d look at something like the cht-config-library? An instance for e2e testing might fit and further, I think even having a public facing instance of this would be handy to easily see how a specific feature works!
Oh, great suggestion, @mrjones .
Do we publish or publicize cht-config-library somehow? I don’t see it mentioned on the forum or any mention of it on the docs site.
Thank you both for the feedback! Great to see that we are aligned on this!
Do we publish or publicize cht-config-library somehow?
Short answer is, “no”. I have been slow-cooking that repo for awhile, gradually adding to it as I have had the need to test various features, etc. I just did this in a personal repo since I really don’t want to clutter up the medic org with random experiments. However, I figured if it got to the point where it seems useful I could transfer it to the medic org and we can make it more official (links from the docs, maybe move some of the stuff out of support-scripts etc). Sounds like maybe the time for that has come!
IMHO I think the most useful breakdown of our various configs would be:
cht-core/config/default - simple production-ready configuration that models a number of actual workflows that would make sense in a real-world environment without being too complex. Can be tested via the cht-conf-test-harness.
cht-core/tests configs - for both the e2e and the cht-form integration tests, either the test scenario is so simple that we can just reuse config/default config OR it is so specific that we just need to have purpose-built config for for the test. I do not think it is worth it to try and make that purpose-built config also be a convenient sample reference for app-devs trying to build new config.
cht-config-library - contains config demonstrating specific functionality with the goal of being a useful reference for how to achieve certain behaviors (without trying to model actual production workflows). Can be tested via the cht-conf-test-harness.
Sure there will be some duplication/overlap between each of these, but I think the benefits provided by each are significant and distinct enough to justify it…
So, my proposal now is that I delete config/demo AND that I push cht-config-library into the medic org (where we can gradually continue to expand it and reference it from the docs). How does that sound?
(The main tricky part for moving the cht-config-library is that the CI tests need a Google Service Account configured in order to properly test the fetch-forms-from-google-drive functionality. Currently the repo is doing this with creds tied to my Google account, but it would be better to use a different utility account…)
Hi all, thank you so much for your input. Most of community members have been requesting for an integrated CHT app as a demo app which would allow them to learn and experience how CHT supports many use cases, the current CHT demo app only supports ANC and PNC usecases. We had proposed adopting PIH Ref app as a demo app, the Sentinel team has supported in upgrading the PIH code from 3.x to 4.x and updated the immunization workflows. The other PIH workflows will be worked on soon.
Is there any concerns over using the PIH app as the demo app?
This is a great idea. The Yendanafe app provides a comprehensive and field tested workflow suite that can - beyond serving as a demo app, provide a starting point for partners with similar use cases.
This seems like a good idea to me as it would provide a more detailed picture of available CHT functionality vs the basic default config you get out of the box. We would need the config to run on the latest version of CHT…
I have been slow-cooking that repo for awhile, gradually adding to it as I have had the need to test various features, etc. I just did this in a personal repo since I really don’t want to clutter up the 