I've modified the branch - https://github.com/danwatford/ofbiz-framework/tree/docker-from-gradle - to allow building the base image with data which is then reused for subsequent builds which include the developer's local changes.
With the branch checked out I created my base image using: ./gradlew buildOfbizBaseDockerImage I then wanted to test PR 192 (OFBIZ-11800) so did the following: git fetch origin pull/192/head:pr192 # Create branch pr192 based on the pull request at the origin repository - in my case https://github.com/apache/ofbiz-framework git merge --no-commit pr192 # Merge the pull request branch into my workspace, but don't commit any changes. ./gradlew buildOfbizDockerImage # Build a docker image based on my current workspace, therefore including the pull request changes. docker run -it --rm --publish 8080:8080 --publish 8443:8443 ofbiz:latest # Run ofbiz using the docker image build above, including the PR changes. On Sun, 22 Nov 2020 at 10:24, Daniel Watford <d...@foomoo.co.uk> wrote: > Some areas which could be improved on: > > - Building an image requires all gradle dependencies to be downloaded. > > Since the docker image is built in isolation, it doesn't benefit from the > gradle cache already populated on the developer's host. This causes lots of > dependencies to be downloaded. > > A possible solution might involve a gradle task to export > ofbiz's dependencies into a temporary directory so that they can be copied > to and imported into the docker image's gradle cache. I'm not sure how to > do this yet. > > > - Builds require loading all data. > > Using something like docker in development will only be useful if building > docker images is fast. Performing a full build and data load takes quite > some time - further exacerbated by the downloading of dependencies > described above. > > One solution might be to create a base docker image with the majority of > dependencies downloaded, software built and data loaded. The developer > would recreate this base image from time to time. > Then a second image is built upon the first which brings in new changes > relevant to the developer's current task. The usefulness of this approach > will depend on the task at hand though. > > For example, if I want to exercise a PR: > > At some earlier point in time I have checked out the trunk branch and run > './gradlew buildOfbizBaseDockerImage'. > > Then later I want to test out a PR I can run 'git fetch origin > pull/1234/head:pr1234; git merge --no-commit pr1234; ./gradlew > buildOfbizDockerImage'. > > The second image built will depend on the first so will benefit from the > already populated gradle cache, the majority of the code already built and > the demo data already loaded. > We can improve on the tagging of the image by reading the branch name from > the development environment using this in the tag name, allowing the > developer to have various images built which address different PRs. > > > > > > On Sat, 21 Nov 2020 at 22:10, Daniel Watford <d...@foomoo.co.uk> wrote: > >> Hello, >> >> Following on from the various docker discussions I wanted to mention an >> approach of building a docker image based on the current development >> workspace using gradle. >> >> Please give it a try - danwatford/ofbiz-framework at docker-from-gradle >> (github.com) >> <https://github.com/danwatford/ofbiz-framework/tree/docker-from-gradle> >> >> I have run these steps on a Windows 10 PRO machine, running commands from >> git-bash. >> >> To build the ofbiz image: >> ./gradlew --no-daemon buildDockerImage >> >> This will create an image, tagged ofbiz:latest, based on the current >> workspace with all demo data loaded. >> >> To run the image in a container: >> docker run -it --rm --publish 8080:8080 --publish 8443:8443 ofbiz:latest >> >> Visit https://localhost:8443/partymgr >> Username / Password: admin / ofbiz >> >> The above container will be deleted when the process is terminated. >> >> The approach of building the image from the current workspace might be >> useful as a way of quickly testing out PR merges. >> Further, by building from gradle we can change the content of the docker >> image based on build properties or environment variables. For example >> we could build multiple images with various database drivers already >> included (where licensing permits). >> >> I wonder if the dev community sees any value in the gradle build approach >> compared to manually creating Dockerfiles either directly in the >> ofbiz-framework sources or held in another repository. >> >> Thanks, >> >> Dan. >> >> -- >> Daniel Watford >> > > > -- > Daniel Watford > -- Daniel Watford
