Youāll see that there is nothing committed since 1.13.0 that will have any meaningful impact on your current distribution. Iād just stick with 1.13.0.
@ibacher from a Maven perspective we would be good to release a first alpha. However we need to understand how to ensure that this 3.0.0-alpha also encompasses the same fixed snapshot of the frontend. Could @ruhanga and yourself liaise to make this happen and establish that process?
This is important because we know that another 3.0.0-alpha.2 will follow suit shortly, presumably with the same backend and with an updated frontend.
I actually donāt think thereās anything that needs to be done here as long as weāre clear that the 3.x RefApp currently just releases Docker images and not any other packaging or artefacts for now (weāve still got a long way to go before we can replace the 2.x RefApp with a 3.x version). Thatās because our Docker images all embed the runtime files, so we already have a fixed set of frontend modules.
Yes, but only because we arenāt publishing something (like with the 2.x RefApp) that allows you to recreate the build. The Docker image for the frontend will be fixed, resolved versions (albeit currently with pre-release numbers).
Even if weāre not publishing those through the build, if only for setting things straight as per the release tag, I think I would feel more comfortable if the actual versions are set there.
This would be just for the release tag, we would bump them up to next right after for the commit setting the next development iteration.
@ibacher I donāt like (at all) the idea that the distro isnāt reliably producing and packaging all the artefacts that it is made of. This sounds like an anti-pattern to me, or at the very least a weaker pattern. And I donāt like the idea that the distro would be just the backend distro - we have no use of this within Ozone.
Perhaps there are compelling ways to have diverted from the original pattern of a fully reliable and rebuildable distro, in which case I am all ears But if those were shortcuts to get quicker to a place solely focused on producing Docker images for the frontend, then we need now to finish this up and be in a world that achieves both goals:
Software distros that can be reliably built.
Docker images made available when they should (like it is now).
Iād definitely be interested in learning more about where we currently are with this. Iām not sure Iām up to speed. @mksd - it sounds like you are saying that we are only producing a Docker image now for the backend, and outside of that Docker image there is no artifact that represents the backend (eg. a zip of the war + modules), the frontend, or the entire distribution (backend, config, frontend)? I would tend to agree that a Docker image is secondary to producing the actual distribution artifacts, which may or may not be run in Docker.
So my understanding is that for the backend + (backend) config, all is fine, you will get all this out of the Maven build of the distro. However the frontend artefacts will be missing, and I would like to add them back (it used to be the case months back).
So, first, I fully agree that where we are is not an ideal situation. We moved away from using the SDK for everything because itās proven hard to keep things working stably with the SDK. Some parts of the frontend build needed to be wrangled to be able to consistently reproduce builds (this still isnāt completely done, but the most pressing things are fixed). A second aspect of this is just that the SDK-based built was, for various reasons, quite wasteful of disk space, which needed to be fixed to have a pipeline that regularly worked. There are some parts of the SDK that need to be revised a bit to generate an output thatās more suitable for the images weāre now using and the SDK should be changed to actually use those same outputs. Also, right now, the distro is currently also hosting the metadata, which is not an ideal setup. Ideally, weād actually have at least two metadata repos, one focused on the metadata to make things work and one focused on the additional metadata we need for demo environments. Those repos / maven modules / etc. should be setup to produce some kind of artefact that the SDK is setup to consume (this probably means integrating some kind of metadata namespace that will download a zip of metadata and unpack it into the appropriate location in the distro). Finally, I think we need to look into the output produced by the SDK and change it to match the conventions implied both by our current Docker images and the 3.x RefApp build.
With those steps done, it should be possible to return the RefApp build to using the SDK to actually produce the build, which gets us several steps closer to where we want to be. The last bit of clean-up is ensuring that the setup commands actually work with this and have some āspecialisedā logic to handle installing module-spa if a 3.x frontend is included.