Break out Addons injection module to own repository

[agjohnson]

trafficstars

While we use the module directly here in local development, it feels very hidden and disconnected from the rest of Addons. Users looking to report issues with the injection are probably looking at our main repository or the Addons repository. This module might be better authored and maintained in one of those locations instead.

I encountered this wanting to add tests to the script

• #225

It seems like we'd need:

• [ ] Move to Addons repo or separate repo entirely?
• [ ] Community/commercial Dockerfile checks out or reuses ${PWD}/${RTDDEV_PATH_ADDONS:-../addons}:/usr/src/app/checkouts/addons similar to other repo reuse
• [ ] Docker compose builds addons inject wrangler image from Git HTTPS URL
• [x] Wrangler uses configuration file instead of hardcoded configuration in docker compose
• [ ] CircleCI config

[humitos]

I'm not opposed to move it to its own repository, but I wanted to note the work required won't be trivial. I've put it in common/ because it's the way we currently have to share code between multiple repositories. In this particular case, we need to share it with readthedocs.org, readthedocs-corporate and also readthedocs-ops.

I'd propose starting by adding whatever is needed to run/write tests into this common repository first and grow from there if it's required, instead of the other way around.

Users looking to report issues with the injection are probably looking at our main repository or the Addons repository

I'm not worried about this. I see this script more as internal ops than user exposed. I'm fine if it's not super discoverable. In fact, it was originally inside ops but I had to move it because of the sharing between repositories needs.

[agjohnson]

because it's the way we currently have to share code between multiple repositories

We also check out ext and ext-theme to their own repos during the docker image build instead of using submodules. I also like this pattern and prefer it over the common submodule.

I'd propose starting by adding whatever is needed to run/write tests into this common repository first and grow from there if it's required, instead of the other way around.

This is already happening in #227

• #227