VHP4Safety / cloud

VHP4Safety Cloud Service Catalog
https://cloud.vhp4safety.nl/
0 stars 1 forks source link

BridgeDb webservice seems old version #42

Closed egonw closed 1 month ago

egonw commented 1 year ago

Compare:

See also https://github.com/VHP4Safety/cloud/issues/40

egonw commented 1 year ago

It needed a new BridgeDb Webservice release to create the new Docker, which is now available: https://hub.docker.com/layers/bigcatum/bridgedb/3.0.22-2.1.4/images/sha256-56eb3a2d82ae9244ac79a3992f3750fe71bf8a063b623e91d9516e96e193f199?context=explore

ozancinar commented 1 year ago

It's updated.

egonw commented 1 year ago

For /config I get this:

java.version    11.0.16
bridgedb.version    3.0.20
webservice.version  2.1.0
ozancinar commented 1 year ago

I checked as well, is it correct?

I just checked http://webservice.bridgedb.org/config which gives

java.version    17.0.5
bridgedb.version    3.0.21
webservice.version  2.1.3

So, there's something wrong with the container on our servers. I'll check it and try to re-deploy the container.

ozancinar commented 1 year ago

@egonw Could you please check this file? It is run in the Dockerfile. In the 7th line, the webservice version is set to 2.1.0, which in turn downloads that old version in the 12th line. This may be the reason for the problem we have in this issue.

Although, I spoke to Marvin just now, and he says that the version number should be updated in the Github action that created the Docker image. I could not examine and understand the code for the action so far, but I will discuss it with Javi when I see him.

ozancinar commented 1 year ago

Following the previous comment; In the Github action, the webservice version is updated in the 52nd line with the BRIDGEDBVERSION="${{ env.BDBWSVERSION }}" part (if I understand it correctly). However, the environment name for the webservice version number in the setup file is BRIDGEDBWSVERSION, not BRIDGEDBVERSION. I don't know if this is the reason but will discuss it with Javi.

egonw commented 1 year ago

Ah, good detective work! Yeah, that version should not be hardcoded there (cc @marvinm2), I guess. I update the setup.sh file and that triggered this Action:

image

ozancinar commented 1 year ago

Just adding @jmillanacosta

ozancinar commented 1 year ago

I tried deploying the container yesterday after the new version number had been hardcoded in setup.sh. However, it still had the same issue, i.e., the versions were still old under /config.

I redeployed it again today, and it is working now (*see below); https://bridgedb.cloud.vhp4safety.nl/config shows this:

java.version    11.0.16
bridgedb.version    3.0.22
webservice.version  2.1.4

https://bridgedb.cloud.vhp4safety.nl/swagger/ also seems to be running. However, if you 'Try it Out' in Identifiers/Get, you'll see that it still leads to a CORS issue. This does not happen if you try the same thing from the IP:port connection, i.e., http://81.169.225.178:8097/swagger/ does not lead to the CORS issue.

I redid the nginx and certbot configurations from the beginning. The CORS issue remains, but maybe it is due to the certbot/nginx configuration starting to be in effect after some time.

* The deployment may be running the latest version due to the hardcode change in the setup.sh file made by Egon two days ago. So, the issue with automatically updating the version number in the Github action may still be effective, although it is tackled just now (see the link above).

egonw commented 1 year ago

Can it be that you get the CORS because the server is not the domain name but an IP address?

image