Closed egonw closed 6 months 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
It's updated.
For /config
I get this:
java.version 11.0.16
bridgedb.version 3.0.20
webservice.version 2.1.0
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.
@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.
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.
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:
Just adding @jmillanacosta
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).
Can it be that you get the CORS because the server is not the domain name but an IP address?
Compare:
See also https://github.com/VHP4Safety/cloud/issues/40