Automatically deploy latest to a site

[vorburger]

It could be useful to automatically deploy the latest community app somewhere.

This could be implemented by reusing the Dockerfile.

It should be triggered by a GitHub Action.

Deployment could be e.g. to https://cui.fineract.dev

[edcable]

@vorburger Thanks for creating this issue. I like the suggestion to use GitHub Action - we're also trying to get that in place for our mobile app repositories. I would be in favor of pointing it to https://cui.fineract.dev so we know this staging instance is fully on upstream, both back and front-end.

[vorburger]

I thought further about this, and have a new thought: Inspired by how https://github.com/openMF/web-app#getting-started-using lives at https://openmf.github.io/web-app/ (waiting for openMF/web-app#1256 BTW...), why even have a https://cui.fineract.dev at all?!

Thinking about this again in retrospect, I now think setting it up like that was actually a mistake I made (one learns and is always wiser in hindsight!), because there really is nothing "fineract.dev" related to it! It's just... the UI - which thanks to that baseApiUrl can be used with ANY back-end server - fineract.dev, mifos.io, privately hosted, localhost dev - whatever! (And we REALLY should support the same feature ASAP in the web-app as well IMHO, as per openMF/web-app#786; pretty please have someone implement that @edcable?)

So what I will do for this issue here some time is instead to simply set up something like https://openmf.github.io/community-app/ - and then delete https://cui.fineract.dev. Makes sense?

[vorburger]

#3323 blocks this, and needs to be fixed, first.

[vorburger]

Actually this project has had https://openmf.github.io/community-app serving https://github.com/openMF/community-app/tree/gh-pages for years, but it was last manually updated 3 years ago by @botraunak and before that 7 years ago by @Nayan. What I'll do in this issue is to have the gh-pages branch auto-updated after every commit.

PS: I've enabled Enforce HTTPS on https://github.com/openMF/community-app/settings.

[vorburger]

FTR: The https://docs.travis-ci.com/user/deployment/pages/ which I've added in e8eb09d, inspired by https://github.com/openMF/web-app/blob/master/.travis.yml, initially failed with:

invalid option "--token="

This is because no GITHUB_TOKEN env var was configured yet in Travis' Settings for this repo. But I obviously cannot publish a Personal Access Token of @vorburger granting push access to all my public repos to Travis (security... Jesus Christ, Travis CI GitHub - srsly?!?! @TravisCI How about at least supporting repo specific Deploy Keys instead of user Personal Access Token?).

However, re-using the https://developer.github.com/v3/guides/managing-deploy-keys/#machine-users account https://github.com/mifos-bot originally created for #3112 is a good fit here - I've created a PAT under that account (the bot didn't mind...), and used that instead.

Note that it was important NOT to limit GITHUB_TOKEN only to the master branch; I initially tried that, and it still failed. Presumably this is because the Travis CI deploy plugin does something like a git checkout gh-pages (that would make sense), so now it's configured for all branches.

With that, https://github.com/openMF/community-app/commits/gh-pages has the first new commit in years, by @traviscibot, yay.

https://openmf.github.io/community-app therefore now always contains the app built from the master branch of this repo.

I'll now update the README accordingly (as agreed on private chat with @edcable).