Adds OpenRefine one-click app.

[nicopace]

Implements #19 .
You can test it out in here: http://openrefine.demo.guardianconnector.net/
user/pass in caprover, or ask Nico.

[nicopace]

One thing to consider is expressed in the documentation for OpenRefine:

OpenRefine has no built-in security or version control for multi-user scenarios. OpenRefine has a single data model that is not shared, so there is a risk of data operations being overwritten by other users. Care must be taken by users.

And the other relevant comment in that documentation is about integrating openrefine in data pipelines:

Some users may wish to employ OpenRefine for batch processing as part of a larger automated pipeline. Not all OpenRefine features can work without human supervision and advancement (such as clustering), but many data transformation tasks can be automated.

[nicopace]

For auth, something like this would need to be set:
https://github.com/auth0/shiny-auth0

Although it was implemented for shiny apps, it should serve our purpuses just fine: https://auth0.com/blog/adding-authentication-to-shiny-server/#Step-2--Get-Nginx-Up-and-Running

[IamJeffG]

Is anything about this specific to or quirky about the way we suggest deploying the Guardian Connector stack? If not, and if this is a general-purpose app, I wonder if it's better to post a PR at a different one-click repository. That will help far more people use this (not just our partners).

At the same time: I really do not want to be in the business of hosting Caprover one-click-apps. The only reason a couple do happen to be in this repo is they are really and truly native to the Guardian Connector stack (not general-purpose) or the deployment is kinda quirky and not the recommended path for how most people should install it.

If no objections to that philosophy, I will take it as a TODO to document this in https://github.com/ConservationMetrics/gc-deploy/blob/main/caprover/one-click-apps/README.md

[IamJeffG]

There's a meta-question here: "What is the GC stack?"

Yeah, we happen to use CapRover to deploy the apps in the stack. Does that mean the stack is everything that can be deployed with CapRover, i.e. everything with a Docker image?

How do we know when OpenRefine is "officially" part of the GC Stack that we support? (And this question stands whether the one-click-app definition ends up landing in this repo or the official caprover one-click-app repo)

[rudokemper]

There is value in depositing the one-click app definitions for apps we are testing out somewhere, though - in particular if they probably should not be merged to the main CapRover repository. (For example: it's yet another tool where we had to cull the process of spinning up a bespoke Postgres server, so the one-click app dfn is targeting deployment on GC, even if it is not "officially" part of the stack.)

Maybe a middle ground is to put them in gc-programs, and to only commit them to gc-deploy if and when we absolutely know it is part of the stack.

[IamJeffG]

Yeah, I think there are two hidden costs to a one-click-app definition:

• The cost of creating the one-click YAML in the first place. If we are just taking a new idea for a spin, in many cases you could deploy it from a docker image directly in the CapRover console. Of course I understand if you already have a docker-compose.yml and there are many services then a one-click-app definition is a natural starting point.
• The cost of maintenance: who is responsible for maintaining this one-click-app definition the future? If someone wanders upon our one-click repo and wants to run OpenRefine outside of the GC context, and files a bug report, what is our course of action? (technically the official caprover one-click repo has this same challenge: they make you commit to maintaining any apps you add.) Putting it into a private repo as @rudokemper suggested skirts this issue.