Re: Lazy consensus: Build docker container images for the release22.01 branch and demo-next site
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 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 > > 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
Re: Lazy consensus: Build docker container images for the release22.01 branch and demo-next site
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 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.
Re: Lazy consensus: Build docker container images for the release22.01 branch and demo-next site
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 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
Re: Lazy consensus: Build docker container images for the release22.01 branch and demo-next site
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.
Re: Lazy consensus: Build docker container images for the release22.01 branch and demo-next site
Thanks Daniel, After our private discussion, this is reassuring :) Jacques Le 11/04/2023 à 12:07, Daniel Watford a écrit : Hi Jacques, INFRA have confirmed (https://issues.apache.org/jira/browse/INFRA-24446) that they have not put constraints on how we securely run processes in the VM, but have also provided some advice to help with ( https://issues.apache.org/jira/browse/OFBIZ-12795). I'll double check script file permissions on ofbiz-vm1, but those permissions you mentioned seem reasonable to me. Thanks, Dan. On Sat, 8 Apr 2023 at 10:09, Jacques Le Roux wrote: Hi Daniel, I think that reading https://github.com/apache/ofbiz-tools/tree/master/demo-backup/ofbizdocker#readme answered my question. There ofbizdocker user is taking the same role than ofbizDemo user. I though noticed that ofbizdocker has permissions 0755 on pull-rebuild-restart.sh, not 0775 has mentioned in https://github.com/apache/ofbiz-tools/tree/master/demo-backup/ofbizdocker#readme ofbizDemo has permissions 0764 on batch files. I guess all is OK, right? TIA Jacques Le 07/04/2023 à 19:41, Jacques Le Roux a écrit : Hi Daniel, I have no problems with that. BTW what about my question concerning "RUN-DEMOS-AS-ofbizDemo-USER-ONLY-NOT-ROOT"? cf. https://lists.apache.org/thread/92ylovhsh9jl9r37448s487blvzq3vfy TIA Jacques Le 06/04/2023 à 21:25, Daniel Watford a écrit : 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.
Re: Lazy consensus: Build docker container images for the release22.01 branch and demo-next site
Hi Jacques, INFRA have confirmed (https://issues.apache.org/jira/browse/INFRA-24446) that they have not put constraints on how we securely run processes in the VM, but have also provided some advice to help with ( https://issues.apache.org/jira/browse/OFBIZ-12795). I'll double check script file permissions on ofbiz-vm1, but those permissions you mentioned seem reasonable to me. Thanks, Dan. On Sat, 8 Apr 2023 at 10:09, Jacques Le Roux wrote: > Hi Daniel, > > I think that reading > https://github.com/apache/ofbiz-tools/tree/master/demo-backup/ofbizdocker#readme > answered my question. > There ofbizdocker user is taking the same role than ofbizDemo user. > > I though noticed that ofbizdocker has permissions 0755 on > pull-rebuild-restart.sh, not 0775 has mentioned in > > https://github.com/apache/ofbiz-tools/tree/master/demo-backup/ofbizdocker#readme > > ofbizDemo has permissions 0764 on batch files. > > I guess all is OK, right? > > TIA > > Jacques > > Le 07/04/2023 à 19:41, Jacques Le Roux a écrit : > > Hi Daniel, > > > > I have no problems with that. BTW what about my question concerning > "RUN-DEMOS-AS-ofbizDemo-USER-ONLY-NOT-ROOT"? > > > > cf. https://lists.apache.org/thread/92ylovhsh9jl9r37448s487blvzq3vfy > > > > TIA > > > > Jacques > > > > Le 06/04/2023 à 21:25, Daniel Watford a écrit : > >> 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
Re: Lazy consensus: Build docker container images for the release22.01 branch and demo-next site
Hi Daniel, I think that reading https://github.com/apache/ofbiz-tools/tree/master/demo-backup/ofbizdocker#readme answered my question. There ofbizdocker user is taking the same role than ofbizDemo user. I though noticed that ofbizdocker has permissions 0755 on pull-rebuild-restart.sh, not 0775 has mentioned in https://github.com/apache/ofbiz-tools/tree/master/demo-backup/ofbizdocker#readme ofbizDemo has permissions 0764 on batch files. I guess all is OK, right? TIA Jacques Le 07/04/2023 à 19:41, Jacques Le Roux a écrit : Hi Daniel, I have no problems with that. BTW what about my question concerning "RUN-DEMOS-AS-ofbizDemo-USER-ONLY-NOT-ROOT"? cf. https://lists.apache.org/thread/92ylovhsh9jl9r37448s487blvzq3vfy TIA Jacques Le 06/04/2023 à 21:25, Daniel Watford a écrit : 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.
Re: Lazy consensus: Build docker container images for the release22.01 branch and demo-next site
Hi Daniel, I have no problems with that. BTW what about my question concerning "RUN-DEMOS-AS-ofbizDemo-USER-ONLY-NOT-ROOT"? cf. https://lists.apache.org/thread/92ylovhsh9jl9r37448s487blvzq3vfy TIA Jacques Le 06/04/2023 à 21:25, Daniel Watford a écrit : 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.
Lazy consensus: Build docker container images for the release22.01 branch and demo-next site
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
