Refactors for dev.est deploy

[tokland]

Required by https://app.clickup.com/t/bpzh7p

• Make Config an entity with repository and use cases.
• Add urlMappingsSource to config: { type: "static" } | { type: "url"; url: string }.
• Add DHIS2_CONTEXT as an environment variable to portainer deploy. This way we can use the same d2-portainer-config branch for all our instances: https://github.com/tokland/d2-portainer-config/tree/https-generic

[ifoche]

I've successfully tested it with eyeseetea/dhis2-data:2.34-WIDP-DISCOVERY-MAL-VEN, but I've configured a new instance for eyeseetea/dhis2-data:2.34.3-WHO-DEV and I'm struggling making it work. Re https thing, everything looks fine, as the instance ready and working, but I hesitate to approve the PR until I make it work just to be sure. I think it's very unlikely that d2-portainer is in the origin of the problem and probably it's related to the server. I've increased the docker partition in 10GB to solve a first free space problem but still I'm getting a blank dhis2, just like if the DB was not able to be injected. I think I'll wait for a conversation after holidays in order to approve it and debug the problem.

[ifoche]

In any case, just for reference, I've changed the repo the config file points to so eyeseetea's one is used: https://raw.githubusercontent.com/eyeseetea/d2-portainer-config/master/config.json

and likewise I've recompiled d2-portainer in /usr/local/bin/d2-portainer after pulling the change with

yarn install
PUBLIC_URL=/d2-portainer REACT_APP_PORTAINER_URL=/portainer yarn build

and obviously added the /who-new-dev/ entry in nginx sites config file (the secure one)

[tokland]

I've also had problems with 2.34.3 when using d2-docker and jetty-runner, a flyway migration raised an exception. I didn't look into it (finally, I used another image) but I think @idelcano had found some workarounds.

[idelcano]

I've also had problems with 2.34.3 when using d2-docker and jetty-runner, a flyway migration raised an exception. I didn't look into it (finally, I used another image) but I think @idelcano had found some workarounds.

@tokland I haven't really tested it myself (yet), but the flyway rules have a version number, if you look at the table select * from flyway_schema_history; You will see that one is missing (I think that it is 2.34.23 or 2.34.24) Deleting the following (2.34.35 and 2.34.36) the flyway applies all the migrations.

Not an ideal solution... but should works

You could also avoid the flyway error by adding the missing rule to the flyway table with the code showing the error, for example:

74 | 2.34.23 | Add sequentialcounter procedure | SQL | 2.34/V2_34_23__Add_sequentialcounter_procedure.sql | -1217080339 | dhishq_usr | 2020-12-14 18:58:41.102536 | 4 | t

[ifoche]

@tokland @idelcano I understand what you say, but I think it shouldn't be that one the problem we're having. I'm able to run the same exact image without issues in my local machine without any issues.

[tokland]

Error response from daemon: error while removing network: network d2dockereyeseetea2343whodev_default id

Oh, I see, it's a specific problem with docker/docker-compose. Good you found a workaround, we'll check next week and see if just restarting the daemon solves it.