Ideas for optimising the development process, e.g. Docker images and CI/CD

Hello Jitsi developers. First of all: Thank you for creating this awesome software. We set up a small server with ~100 users which we’ll want to scale to a slightly bigger installation with about 20.000 users. We have a few ideas and wanted to know your feedback before jumping in head over heels.

Follow Jitsi upstream with Docker tags

While setting up Jitsi in a docker-compose environment, we became confused several times due to the nature of the Jitsi development process. As we’re not familiar with the codebase, it was pretty hard to find out which upstream version of jvb or prosody the image tags correspond to.

For example, if you want to know which software versions are in tag 4384, you’d have to correlate the dates of the jvb release with the docker build date.

Would it be possible to tag the images in a more intuitive way, so that one can ascertain directly which version the image corresponds to? For example if you use prosody 0.11, the docker image tag could be named prosody/0.11-build4384 or something like that.

Jenkins Tags / Git workflow

Currently, it seems like you’re auto-tagging releases with Jenkins after every commit to master on Github, e.g. for Jibri:

In our opinion, this is too verbose for an end user/admin. While scrolling through >3800 tags it’s not directly clear which changes occured in a release.

What Jenkins is doing is apparently just zipping the repository, not creating a runnable release, is that correct? Example: https://github.com/jitsi/jitsi-meet/releases

Versioning / Releases

You sometimes push directly to master, which again leads to Jenkins creating a new tag. Maybe the popular git-flow model would be beneficial for clarity. You could have a single “stable” branch (possibly master?) and only merge after someone reviewed the changes.

We think properly following SemVer/git-flow and having clearly worded change logs would be nice. Automatically tagging releases was a source of confusion for us, as described above.

Maybe internal releases don’t need to be published to the public. Tagging only “proper” releases which are ready and stable to use would be awesome.

Upstream Docker images

It would be cool if you could make more use of upstream docker images and try not to cook own images based on Debian.

For example, maybe nginx doesn’t need to be built based on a Debian base image if you only change the config files. There’s an official docker image for nginx which can be extended. These images have the advantage of being optimised for Docker usage and having more recent releases of nginx built directly from source into a Docker image.

Prosody’s official image on the other hand is borked, too – they use the Debian 9 “stretch” repository even though their github repository for Docker shows FROM debian:10 in the first line of their Dockerfile. While we’ll try to resolve this with Prosody upstream, we wouldn’t recommend using their Docker image. In the meantime you could maybe try using Debian 10 as a base image? The current setup leads to using Debian 9 with a backports repository for Prosody, which is a tad weird in our opinion as both Jitsi and Prosody seem to support Debian 10 “buster”.

What we can do for the project

We’re able to throw money onto this and possibly also contribute code/Pull Requests if the path you want to take is clear.

We’d like to start a discussion about the proper way to – possibly – restructure the development/deployment process to make it easier to contribute to the project, but of course do not want to overturn any decisions made by the dev team.

Kind greetings from Mannheim, Germany,
@itronik and helix

1 Like

@saghul @awlnx do you have thoughts?

Are our ideas sensible changes or is it the wrong direction?

Do you think our inconveniences are valid or will we just need more time to familiarise ourselves with the Jitsi/Meet codebase?

That shouldn’t be the case, we tag each repo with “stable/jitsi-meet_XXXX” and that XXXX is what the Docker tags correspond to.

We could tag them differently, but I don’t know how your proposal makes it any different. It’s still an obscure number. Or do you want to see that Prosody was 0.11 there? IMHO that should be irrelevant here.

We have made strides to simplify this, but haven’t finished the effort yet.

A Jitsi Meet installation is comprised of multiple components. The tags allow one to know what exact code is distributed in the Debian packages we build, which have the same number.

This is somewhat intentional. As the original author of our images, here is what I am after: familiarity. All images share the distribution and fs layout, this simplifying administration for users.

We run Debian / Ubuntu in production, so that’s the only distributions we can support, thus we are not interested in running any component with Alpine or anything else, for example.

We recently changed Prosody to use the official Debian repo so we could get a more up to date version. We could do the same for Nginx, should there be an official repository.

Everybody seems to have a preferred flavor when running Docker, and well, this one is ours. It is by no means perfect, but it aims to be consistent and easy to navigate.

We welcome any and all contributions (the Docker repo has gotten a significant spike in activity lately) but the guidelines above remain.

You mentioned making contributing easier. Can you elaborate on why it’s not easy to contribute now? I’m asking because this is the first time I’ve heard it in relation to the Docker setup.

Thanks for getting in touch and being willing to help!