Running openmrs instance on bamboo via docker

, , ,

I want to create a testing instance for running my tests on bamboo. Refer to Reference Application - Distribution 3.x E2E: Plan summary - OpenMRS Bamboo

  1. remove previous docker data
docker system prune -a -f --volumes && docker network prune -f && docker network create web-app
  1. run the database
  docker run -dp 3306:3306 \
     --network web-app \
     --name mariadb \
     -v "db-data:/var/lib/mysql" \
     -e MYSQL_DATABAS=${OPENMRS_DB:-openmrs} \
     -e MYSQL_USER=${OPENMRS_DB_USER:-openmrs} \
     -e MYSQL_PASSWORD=${OPENMRS_DB_PASSWORD:-openmrs} \
     -e MYSQL_ROOT_PASSWORD=${MYSQL_ROOT_PASSWORD:-openmrs} \
     mariadb:10.8.2 \
     sh -c "mysqld --character-set-server=utf8 --collation-server=utf8_general_ci"
  1. run the backend
    docker run -dp 8080:8080 \
       --network web-app \
       -v "openmrs-data:/openmrs/data" \
       --health-cmd "curl --fail http://localhost:8080/openmrs || exit 1" \
       --health-timeout 5s \
       -e OMRS_CONFIG_MODULE_WEB_ADMIN=true \
       -e OMRS_CONFIG_AUTO_UPDATE_DATABASE=true \
       -e OMRS_CONFIG_CREATE_TABLES=true \
       -e OMRS_CONFIG_CONNECTION_SERVER=db \
       -e OMRS_CONFIG_CONNECTION_DATABASE=${OPENMRS_DB:-openmrs} \
       -e OMRS_CONFIG_CONNECTION_USERNAME=${OPENMRS_DB_USER:-openmrs} \
       -e OMRS_CONFIG_CONNECTION_PASSWORD=${OPENMRS_DB_PASSWORD:-openmrs} \
       openmrs/openmrs-reference-application-3-backend:nightly
  1. run the frontend
    docker run \
       --health-cmd "curl --fail http://localhost:8080/openmrs || exit 1" \
       --health-timeout 5s \
       -e SPA_PATH=/openmrs/spa \
       -e API_URL=/openmrs \
       -e SPA_CONFIG_URLS= \
       openmrs/openmrs-reference-application-3-frontend:nightly
  1. run the getway
    docker run -dp 80:80 \
       --network web-app \
       openmrs/openmrs-reference-application-3-gateway:nightly

Bamboo fails with an error

Force Stop build feature is enabled for current plan. Either Bamboo has detected the build has hung or it has been manually stopped.

full log => Reference Application - Distribution 3.x E2E - Run Instance 7: Build log - OpenMRS Bamboo

cc @dkayiwa @ibacher @raff

the build fails after like 10 minutes

First of all, please get rid of that first step. That’s a terrible series of commands to run, especially by default. There is literally no good reason to flush the Docker cache unless you’re running low on disk space and ultimately, this will make not just this build, but any builds that rely on Docker take substantially longer than they should.

Second, why are you running the containers as separate instances instead of using docker compose and the compose YAML file?

Third, you’re running the frontend in foreground mode… since there are no requests coming in, there’s eventually no output and Bamboo kills the build since it appears to have hung.

@ibacher i tried running with docker compose by:

  1. checking out the GitHub - openmrs/openmrs-distro-referenceapplication at 3.x

  2. Then running docker compose up -d

This did not work. Responded with compose not a docker command maybe docker-compose up -d might work. I have just got that idea now :laughing:

kindly drop me more explanation of what u mean by saying running the frontend in foreground mode

Checking the logs, seams i have deleted all docker cache and reset docker to default. I thought every build is assigned a different runner just like with GitHub actions.

It should… IIRC, we don’t have the compose extension installed, but the older version using docker-compose should work.

Most of your docker commands had the -d flag as part of the run command which instructs Docker to run the container as a background (daemon) process. The command to run the frontend, however, did not have this flag, so it is run as a foreground process. Basically, if you ran the same command locally, if you ran it with-d, the container would start and then you would get your prompt back whereas if you didn’t run it with -d (necessary for any interactive process) your terminal window would be taken over by the docker container.

Even if that were the case, it still wouldn’t be the right thing to do. But, no, we only have 3 runners.

1 Like

@ibacher @dkayiwa, the instance seams to have started correctly with just mere docker-compose up and verification shows its running

timeout --help "Exiting because instance hasn't started in 10 minutes." 10m bash -c 'while [[ "$(curl -s -o /dev/null -w ''%{http_code}'' http://localhost:8080/openmrs/login.htm)" != "200" ]]; do echo "Waiting for server" && sleep 10; done'

however using npm in my task makes the job to execute infinitely (executed for the last 18 hrs without any log or error)

Could this be because node.js lacks a runner agent?

It would greatly help to share the link to the bamboo plan.

https://ci.openmrs.org/browse/REFAPP-D3E

cc @burke

Did you take a look at how any of our current projects that use Node and NPM work?

A few things that stand-out:

  1. There are no active agents that report supporting any version of NPM or NodeJS, so setting up a job that depends on those is bound to fail.
  2. You have a step that runs a shell script that cds into a directory and then does nothing else… This is not going to have the effect you think it will have because the agent won’t track the changed working directory across scripts… Scripts are run in a shell that’s started from the same CWD every time (this is pretty universally true of every CI system I’ve worked with).
  3. The short version is that we have (for better or worse) nvm installed on the agents, so to run an NPM script, you should actually setup a Shell script which runs nvm, selecting whatever version of Node and NPM is appropriate (similar to GitHub Actions setup-node step) and then just run npm run ... where ... is whatever command you need to run, e.g.
nvm use --lts
cd package/cypress
npm run myScript

thank you @ibacher I have made it work.

However the log on failure (because of failing tests) is really not helping to other users. It’s what i am going to try improve

The ideal way to make the test output more understandable would be to configure the test runners to output test results in the JUnit format, at least when run from Bamboo and then tell the Bamboo job where it should look for those test results…