Audit of custom GC repo for one-click-apps: action items

[IamJeffG]

Goal is to make sure this repo's CapRover one-click-app defns are generally useful to those deploying a Guardian Connector stack in organizations outside of ours.

My audit of caprover/one-click-apps identified, in no particular order:

• superset-only.yml hard-codes the guardianconnector.net domain:
  • the superset admin user email
  • FRAME_ANCESTORS: "https://*.guardianconnector.net"
• gcexplorer.yml uses :latest docker tag. This is convenient (pseudo-automatic upgrades, but which we don't control the timing of), however it may also lead to bloat of old Docker images cached on VMs - can lead to disk space issues on resource-constrained VMs
• comapeo-cloud.yml and superset-only.yml point to images on a private container registery (guardiancr.azurecr.io). To use them requires either configuring private credentials via the CapRover dashboard, or to make them public. (which?)

[rudokemper]

• Superset (hard-coding domains): seems like we could solve that by adding 2 more CapRover params? I'd be fine with that.
• GC Explorer: yeah, this is on me: I need to implement versioning and adapt the CI workflow to publish that instead of just :latest. Then we can modify the defn.
• CoMapeo: this can actually be updated, as Awana is now publishing images to https://hub.docker.com/r/communityfirst/comapeo-cloud/ (but also just :latest tag, so might need to recommend versioning or timestamp-based tags...)
• Superset (image publishing): I don't see a reason to keep this private. Do you? We can create a public container registry on Azure and publish it there. In which case, we can either discard with guardiancr.azurecr.io (as a private registry), or keep it around for one-offs when we need it. Like a temporary Landing Page app for testing.

[IamJeffG]

I wonder if we can & should let up about the :latest images -- in particular now that I've been enabling automatic disk cleanup, on a cron, thru Caprover:

Just using :latest does make releases easier (automatic, if out of our control as to when they happen). OTOH it also removes the ability to rollback to a previous release, e.g. through the CapRover dashboard (we rarely use it).

[rudokemper]

I agree that it is not a top priority. gc-explorer CI does publish images for PRs, so there is already a mechanism in place for rollback if needed (albeit not for direct commits to main).