jira 8.18.2 not available on dockerhub

[rwarren]

I just tried deploying jira 8.18.2, but it is not available on dockerhub, despite github being updated 2 days ago (commit dc78fca).

I also tried building the image locally with:

./buildscripts/buildImage.sh jira-software 8.18.2 8.18.2 en US ./Dockerfile

but this image did not start properly after it was built, with docker logs showing a repeat of logs like this:

<snip>
jira                  | executing as current user
jira                  | Cannot find /opt/jira/bin/setclasspath.sh
jira                  | This file is needed to run this program
jira                  | 2021/08/26 17:03:38 Waiting for: tcp://hostdb:5433
jira                  | 2021/08/26 17:03:38 Connected to tcp://hostdb:5433
jira                  | executing as current user
jira                  | Cannot find /opt/jira/bin/setclasspath.sh
jira                  | This file is needed to run this program
jira                  | 2021/08/26 17:04:30 Waiting for: tcp://hostdb:5433
jira                  | 2021/08/26 17:04:30 Connected to tcp://hostdb:5433
jira                  | executing as current user
jira                  | Cannot find /opt/jira/bin/setclasspath.sh
<snip>

Two questions:

1. Is the push to dockerhub not working?
2. What is the correct way to build locally?

[jhult]

8.18.x stopped building on CircleCI (haven't yet determined why). The Docker images build. But the tests to see if Jira is up and running don't work (even waiting 10-20 minutes).

Building locally with something like this works for me:

./buildscripts/buildImage.sh jira-software 8.18.2 8.18.2-jh en US ./Dockerfile

To test running it, update the docker-compose.yml to use the new image tag. Example:

image: teamatldocker/jira:8.18.2-jh

The run:

docker-compose up

[oliverlogghe]

Cannot find /opt/jira/bin/setclasspath.sh

I just tried a new build and have been getting this as well.

What's happening is that [ -r $FILE ] tests are erroneously failing in the bash startup scripts, apparently a result of this bug in Alpine 3.14.

It's a bit maddening because it's a host dependent syscall issue. It'll work on some boxes and not others.

[jhult]

@oliverlogghe, thanks for the research. I was able to fix this by bumping the base image to adoptopenjdk/openjdk11-openj9:x86_64-alpine-jre-11.0.10_9_openj9-0.24.0 which uses Alpine 3.12.7.

This was a bit maddening of a bug indeed!