Re: Lazy consensus: Build docker container images for the release22.01 branch and demo-next site

[Michael Brohl]

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.