Hi, I think the real issue here is that we use GoogleContainerTools's Jib as the build mechanism. It works entirely without a Dockerfile. And unfortunately Dockerhub's Automated Builds doesn't support building without a Dockerfile. :-(
We have two ways to move forward: 1. Replace the Jib build with a more traditional, Dockerfile-based approach. This would be a quite large change of how Fineract is built and the consequences need to be explored - but it's definitely doable. 2. Stick with the Jib build, but don't rely on Dockerhub's Automated Builds, but some other build tools like jib-maven-plugin to publish the image to Dockerhub. This could also work, but it requires a build server that I'm not sure we have. I can try to create a traditional Dockerfile, but it will be different from what Jib can produce, so this might lead to regressions. Want me to try this approach next week? Kind regards, Zoltan On Sun, Feb 11, 2024 at 8:16 AM James Dailey <jamespdai...@gmail.com> wrote: > Victor - my read of the docs is that the default “build rule “ points to > master or main but we can also use dev. In fact that’s what is already > there in dockerHUB for our project. > > I think a proper dockerfile in dev branch should be fine. > > Thanks > James > > On Fri, Feb 9, 2024 at 7:47 PM VICTOR MANUEL ROMERO RODRIGUEZ < > victor.rom...@fintecheando.mx> wrote: > >> Reading the dockerhub docs, I think we can do the following: >> >> 1. Create a master branch from develop branch >> 2. Add the Dockerfile (and some scripting on it for handling the >> versions) on master branch >> 3. Dockerhub will use the dockerfile (and its scripts) from the master >> branch >> 4. Create github action for keeping in sync develop with master, so then >> it will push the changes to the master branch everytime the develop branch >> has a commit on it, then the dockerhub will publish it as the latest >> version. >> >> Or... we can be more standard >> >> 1. Rename develop to master >> 2. Add a Dockerfile template (and some scripting on it for handling the >> versions) on master branch >> 3. Dockerhub will use the dockerfile (and its scripts) from the master >> branch >> 4. Everytime a new commit or tag is created, the dockerhub will publish >> it as the latest/specific version. >> >> What do you think? >> >> Dockerhub automated builds info: >> https://docs.docker.com/docker-hub/builds >> >> Regards >> >> >> >> El vie, 9 feb 2024 a las 20:34, James Dailey (<jamespdai...@gmail.com>) >> escribió: >> >>> Victor - I was trying to go down that path as well, as that is the error >>> thrown and the suggestion at DockerHUB. However, to add the key to the git >>> hub requires access and the git is controlled by Apache Infra. I asked >>> infra@a.o. about that since, again, that is what DockerHUB had >>> documented. Unfortunately, I think infra has it setup a specific way to >>> allow all of the projects to publish to the Apache DockerHUB so that route >>> would appear to be blocked. >>> >>> >>> >>> On Fri, Feb 9, 2024 at 4:04 PM VICTOR MANUEL ROMERO RODRIGUEZ < >>> victor.rom...@fintecheando.mx> wrote: >>> >>>> For making it work without a Dockerfile the credentials of the docker >>>> hub account are requiered. >>>> >>>> If they are set in the git repository, a github action can be enabled >>>> for this task. >>>> >>>> Regards >>>> >>>> El vie., 9 de febrero de 2024 4:45 p. m., James Dailey < >>>> jamespdai...@gmail.com> escribió: >>>> >>>>> I've re-opened https://issues.apache.org/jira/browse/FINERACT-1164 >>>>> >>>>> This ticket is to enable the build at DockerHUB to work. For the past >>>>> two years ++ the Build has failed. >>>>> >>>>> https://hub.docker.com/r/apache/fineract >>>>> This docker account is held by Apache and the Fineract project is >>>>> responsible for the content. >>>>> >>>>> The dockerHUB has an "auto build" concept so that every committed >>>>> change on Dev leads to a new deployment. >>>>> >>>>> The build is actually failing or not running because we have removed >>>>> the dockerbuild file from the root. That is as far as I've gotten. I >>>>> suspect we had good reasons for that at the time. >>>>> >>>>> Anyway, I would also say that if we cannot get the Docker build to >>>>> work THEN we should take this down. Our standard is to only support and >>>>> distribute publicly the last two releases. This build is really old, has >>>>> unfixed CVEs, and is being downloaded in large numbers. (no idea why) >>>>> >>>>> Thanks >>>>> James >>>>> >>>>
