I've reconfigured project and fixed building distribution builds and publication to S3 for https://builds.tigase.net/. Currently, new build should be done every day at 01:00, and new packages should be deployed to build.tigase.net as nightlies.

It was not tested yet if builds are complete and working. TTS-NG tests are also not configured and executed.

Docker/Container images are also not being created yet. For those I think that migration to Maven JIB plugin (or just JIB tool) would be a better option for moving to publication of latest/nightly container images as I would suggest to make this move before restoring Docker image creation on 1dev. Alternatively, we could try using 1dev "Create docker image" feature, but I would prefer to have Maven task for that as it would make manual creation of container image of Tigase XMPP Server locally for testing simpler (and possible without push to the main repository).

Note: We do not rebuild projects daily, but we are using builds done after each push to Tigase XMPP Server subprojects repositories. Thanks to that actual build is faster. If needed we can force nightly "rebuild" but to be honest I do not see a reason we should rebuild all projects if they are built after each push. (At least for nightly builds I do not see a reason for that).

@kobit What do you think? About current state of CI? is it ok for now? If so, I would prefer to fix creation of docker/container images, so we would get nightly images back.

I agree on builds after push only. In our case, we do not have multiple pushes/commits per day, every day, which would justify nightly builds. It makes sense to run build on push.

I also agree on Docker images creation from maven using JIB plugin.

I've converted our container image building done in a separate https://tigase.dev/tigase/_server/tigase-xmpp-server-docker project to be done by JIB maven plugin in this project.

Then I've added execution of JIB maven plugin to Maven CI build step done for this project dailly (scheduled by cron). With that we got automatic daily builds of Tigase XMPP Server working, built for arm64 and amd64 and published on Docker Hub (see https://hub.docker.com/r/tigase/tigase-xmpp-server/).

With that done, we've got daily builds working on 1dev.

However, there was/is a small issue with builds. When builds were done using Docker (docker buildx), multiarchitecture builds were done by execution of commands on running docker images (for each CPU architecture separately, in VM if needed). That allowed us to run jlink to create minified version of JRE that contained only required modules of Java. With JIB that is no longer possible, so to now lose this feature, I've created in tigase-xmpp-server-docker project (https://tigase.dev/tigase/_server/tigase-xmpp-server-docker/) new image specification in directory named jre-17. This new image prepares a base image with trimmed version of JRE that later is used by JIB to build images.

But, as I mentioned, 1dev is unable to build multiarchitecture container images by running command (unless it has access to running instance of Docker, that we do not have on our k8s cluster), this new base image tigase/tigase-xmpp-server-base needs to be built and pushed to Docker Hub manually.

I do not think this is a blocker for us, as we are not changing JRE versions often, so being forced to push new trimmed JRE image at that time, doesn't seem like a big issue.

On the other hand, I think we could use Docker Hub to build this base image for use, if we would give it a webhook call and access tosource code repository of this base image. (I'm not sure, if we would need to pay extra for that or not).

Anyway, I think that it would be good to be able to build multiarchitecture images by running commands directly from 1dev. I've seen that there were some tries done with running docker or with running Kaniko twice (requires having cluster with arm64 and amd64 nodes).

@kobit Should we report this as a request for a new feature to be added to 1dev?

I'm leaving task in IQ to check if automatic build jobs properly builds container images.

@kobit Should we report this as a request for a new feature to be added to 1dev?

Yes. Especially, that sometimes, the 1dev developer has good suggestions or workarounds.

I've asked 1dev developer, see https://code.onedev.io/onedev/server/~issues/1718

As I can see, the developer already responded.

So, what is the best approach for this, in your opinion?

I'm aware of a docker-in-docker project, that is used ie. by Gitea (I think) that could allow us to use docker inside container to build images. I'm not sure if that will work or not, but it is something worth checking, but I haven't got time to look into that.

As I understand, we can consider this task completed for now?

I think this can be closed. I'm looking into usage of dind (docker in docker) right now, but can have a separate issue for that.