Hi Michael, Those changes have been applied to trunk and release22.01. You should be able to sync your repository fork and avoid the build failures related to pushing docker images.
On Thu, 20 Apr 2023 at 11:42, Michael Brohl <michael.br...@ecomify.de> wrote: > Hi Dan, > > sound good! > > I would propose to name the environment variable more explicitely, e.g. > DO_DOCKER_PUSH. DO_PUSH sounds too broad to me. > > Thanks, > > Michael Brohl > > ecomify GmbH - www.ecomify.de > > > Am 20.04.23 um 12:25 schrieb Daniel Watford: > > Hi Michael, > > > > I have just reproduced the issue you raised at > > https://github.com/danwatford/ofbiz-framework by resyncing trunk. > > > > Yes, we can (and should) make the problematic steps skippable/optional. > > > > If you drill into the GitHub Action you will probably find the failure > > occurred at step, 'Build and push runtime docker image'. > > > > If you look at the GitHub Actions definition file, > > $ofbiz-framework/.github/workflows/docker-image.yml, for the 'Build and > > push runtime docker image' step (lines 89-96) we use an environment > > variable to control whether the image is pushed to ghcr.io/apache/ofbiz. > > > > Currently we check to see if env.ACT is unset, but perhaps we should > change > > this to see if an environment variable similar to 'DO_PUSH' exists. We > > would then set that environment variable of apache/ofbiz-framework, but > it > > would be unset on all forks. > > > > I'll raise a ticket. > > > > Dan. > > > > > > On Thu, 20 Apr 2023 at 11:02, Michael Brohl <michael.br...@ecomify.de> > > wrote: > > > >> Hi Dan, > >> > >> the build integration to build docker images seems to break forks and > >> therefore external repositories. > >> > >> When synching our fork, a git actions seems to chime in: > >> > >> === > >> > >> Build and push docker images: All jobs have failed > >> Build and push OFBiz docker container images > >> > >> Build and push docker images / Build and push OFBiz docker container > images > >> Failed in 4 minutes and 2 seconds > >> > >> docker-image.yaml > >> on: push > >> > >> Annotations > >> 1 error > >> Build and push OFBiz docker container images > >> buildx failed with: ERROR: denied: permission_denied: The requested > >> installation does not exist. > >> > >> === > >> > >> Is it possible to configure this in a way that this is optional or must > >> be triggered explicitely? > >> > >> Thanks, > >> > >> Michael Brohl > >> > >> ecomify GmbH - www.ecomify.de > >> > >> > >> Am 06.04.23 um 21:25 schrieb Daniel Watford: > >>> Hello, > >>> > >>> We recently configured the demo-trunk site ( > >>> https://demo-trunk.ofbiz.apache.org/partymgr) to use docker containers > >>> based on images built following commits to the ofbiz-framework trunk > >> branch > >>> (https://issues.apache.org/jira/browse/OFBIZ-12786) > >>> > >>> This work brought about some improvements in how containers are > deployed, > >>> particularly regarding the disabling of specified plugins when a > >> container > >>> is started up. > >>> > >>> The deployment also highlighted that memory constraints applied to the > >>> ofbiz container were too low and that there was a bug in the logic used > >> to > >>> set the password for the tenant database. Both of these issues were > >> quickly > >>> resolved. > >>> > >>> Through deployment of the demo-trunk site as a container, we also > >>> demonstrated how we can alter the configuration of an OFBiz instance at > >>> runtime through the use of scripts which 'hook' into various stages of > >> the > >>> initialisation process. See the scripts used for demo-trunk here - > >>> > >> > https://github.com/apache/ofbiz-tools/tree/master/demo-backup/ofbizdocker/home/ofbizdocker/demo-trunk/after-config-applied.d > >>> > >>> LAZY CONSENSUS > >>> > >>> This email thread is to establish if we have a lazy consensus to > >>> automatically build and publish container images for commits to the > >>> ofbiz-framework release22.01 branch similar to what is currently > >> configured > >>> for the trunk branch. These container images will have container tags > >> such > >>> as release22.01-snapshot. > >>> > >>> Further, GitHub actions will also build container images in response to > >>> tags, prefixed with 'release', being pushed to the release22.01 branch. > >>> These containers will have container tags derived from the git tag. For > >>> example, git tag 'release22.01.02' would result in a container tag of > >>> '22.01.02'. > >>> > >>> This email thread is also to establish if we have lazy consensus to > then > >>> use the release22.01-snapshot container images for deployment of the > >>> demo-next site (https://demo-next.ofbiz.apache.org/partymgr) similar > to > >>> what is currently in place for trunk. The container tags current used > can > >>> be seen here - > >>> https://github.com/apache/ofbiz-framework/pkgs/container/ofbiz > >>> > >>> Using a container for deployment removes the need to have any > >> dependencies > >>> in place on the host OS used for the demo-next site. Dependencies are > not > >>> an issue at the moment, but may become difficult to manage if and when > we > >>> want to vary the JDK used to build and run release22.01. > >>> > >>> Container images produced by the GitHub Actions workflow will be > >> published > >>> to the GitHub Container Registry (ghcr.io). They should only be > >> considered > >>> as a convenience to users who wish to use containers. Container images > >> are > >>> not an official release of the Apache OFBiz project. I am not proposing > >> to > >>> alter any README files to refer to the container images at this time. > >>> > >>> Thanks, > >>> > >>> Dan. > >>> > > > -- Daniel Watford
