Docker-mailserver: Migrating docker-mailserver

[aendeavor]

This is a rather intricate topic, so I will try my best to be as objective and neutral as possible. I'm trying to get as many maintainers in here as possible so we can have a debate about this.

We are currently having two big issues that I would like to have solved:

1. Creating multiarch images within one repository (see #1678)
2. Enabling automated docker builds (with buildx, see 1. and #1207)

@tomav seems to have very little time at hand, but without permissions to the build and test services, there is nothing we as maintainers can do. Therefore, one valuable solution could be this:

Transferring the main development repository to someone else, preferably a (somewhat active) maintainer. This can easily be done with a fork. All current maintainers shall be invited so they can collaborate as before. We can use GitHub actions or another solution to solve 1. and 2. Current issue can be solved here, new issues will be marked so they can be opened in the new repository.

In #1678, @radicand offered to help with the GitHub actions to build for multiple architectures.

I would like to hear what everyone thinks about this - whether this is a possible solution, what's bad, what's good, what is to be improved on; maybe I'm completely missing something? Let's debate on this.

---

All the Tasks - Tracking

Tier 1

• [x] Create a description of how the test suite should work / works, in a clear, concise way, for example with diagrams, etc.
• [ ] As @wernerfred provided a beautiful overview, all actions shall be implemented as described in his post

Tier 2

• [x] See whether GH Organizations brings a benefit in terms of workflow for (multiple) collaborators
• [x] Use GH Actions to build multiarch with docker buildx
• [ ] Create a scheduled build to have the images up-to-date (with GH Actions)
• [ ] Integrate tests into GH actions to only build when tests are successful
• [ ] Integrate automatic parsing / labelling

Tier 3

• [ ] Look into Dependabot
• [ ] Adding Codecov as an action

[erik-wramner]

Well, to be honest I did create my own fork long ago when this project seemed to have stalled, but now I'm only using it for staging and for daily builds. I would prefer to keep this repo if possible as forks tend to fragment the user base. Still, I agree that this is a problem. Hopefully @tomav can find some time to help or at least respond.

We could create a downstream fork that focuses entirely on the build process and that gets the rest from here. That would keep this repo as the main place where work is done and where the issues and documentation is kept, but would allow us to control the automatic builds including support for multiple architectures.

[aendeavor]

I would prefer to keep this repo if possible as forks tend to fragment the user base.

I completely agree.

We could create a downstream fork that focuses entirely on the build process and that gets the rest from here. That would keep this repo as the main place where work is done and where the issues and documentation is kept, but would allow us to control the automatic builds including support for multiple architectures.

I would actually like to keep this repo as the main place of work too. But I think that this implies build + testing should be done in this repo as well:)

[erik-wramner]

Ideally yes. The tests should absolutely run here (and Travis will have to be moved soon as it will shut down in December!). The build could be handled downstream. We still don't build in Travis, as far as I can determine the build is really done in Docker Hub triggered by commits and regardless if the tests succeeded or failed.

[fbartels]

For a moment you had me worried about Travis, but they are not completely shutting down just retiring one domain (the .org one) open source projects are still free on their .com domain.

https://mailchi.mp/3d439eeb1098/travis-ciorg-is-moving-to-travis-cicom

But I agree on the forking topic. The best case would be to create a dedicated organisation on Github and move this repo over. this way Github handles some redirects. The other issue will be the name of the container in the docker registry.

[aendeavor]

I like @fbartels' idea of an organization. I've never worked on one, but this could very well actually solve some problems.

[radicand]

I'm happy to contribute as helpful - I do believe there's opportunity to leverage GitHub actions to drive the CI process (still keeping Travis if beneficial, or everything in GitHub native). With the upcoming holiday I should have some volunteer availability. Just let me know.

[aendeavor]

@radicand that sounds awesome. Can you firstly explain what GitHub actions is capable of without paid features, so we can evaluate whether we can use GH Actions for CI/CD?

We need:

1. Testing of the image
2. Publishing of tests are successful

---

Now, the question remains, to which registry, and how.

[radicand]

Generally speaking, actions are free for public repositories, and have a quota for private repos (2,000 minutes/month at free tier). Because this is a public repository, we won't have the quota enforced and do not need to worry about it.

Within the actions framework (e.g., no external dependencies like Travis), you can run the test suite, build the image, and push it to Docker Hub, and have the steps depend on each other as well.

[aendeavor]

That's exactly what we need. The already proposed idea of an organization in combination with GH Actions seems to be a solution that enables many collaborators to monitor and alter test setup and building of the image with the added flexibility of building multiarch images.

[andreasfaerber]

I would also be interested in the multiarch (in particular arm) builds. I have just "cloned" the repository to create arm builds myself (not only arm64). I am currently doing that with travis-ci. Could also have a look into github workflows for that if that would add some value.

[aendeavor]

@andreasfaerber it would!:) The more people we got with working on this change the faster we can achieve our two goals.

I will have a look into GH Organizations tomorrow.

[aendeavor]

GH Organizations seems to be a valuable solution. In theory, this repository could be transferred and then managed by more collaborators. We could test this out.

@radicand @andreasfaerber when you're researching for the multiarch builds, can you test this with a repo in an organization? It's not very difficult to setup one and transfer a repository - should cost about 5 minutes. That would be great because we could then see whether multiple persons can work in the test and build (GH Actions) suite.

[andreasfaerber]

I have set up a branch for the workflow testing here: https://github.com/test-org-dm/docker-mailserver/tree/gh-workflows

This is within an organization i created. As a proof of concept that workflow can build the docker images for multiple architectures as you can see here: https://hub.docker.com/repository/docker/andreasfaerber/test-dm/tags?page=1&ordering=last_updated

So much for a start. What is it that you would like to test with the organization and multiple people?

[aendeavor]

Looks amazing - thanks for the fast work!

We will now need to sort out whether we want TravisCI in the mix or not. I'm for _not_ having Travis but instead use GH Actions to run the tests as well, if that is possible. @radicand you said it is. Looking at what @andreasfaerber has already achieved, it shouldn't be much of of a hassle to integrate tests in his repo as well, or is it?:)

@andreasfaerber can you invite me and @radicand to your repository as collaborators so

1. @radicand may help you with integrating tests
2. I can have a look at how GH Organizations use role management (if there is role management or something related)

---

From what I can see @andreasfaerber, you are building for

linux/386,linux/amd64,linux/arm/v6,linux/arm/v7,linux/arm64,linux/ppc64le,linux/s390x

Is it possible to build for linux/arm/v8 as well? We may also not need linux/386,linux/ppc64le,linux/s390x - that's up for debate. I'd just like to keep the list as long as necessary but as short as possible.

Moreover, as I'm not very familiar with GH Actions, can you just shortly explain how your setup works?:) Maybe this way I can be of help with the tests too.

[andreasfaerber]

I have added you both to the repository. Regarding the explanation it's fairly simple, even though the environmental variables need some more parsing. The workflow to build the docker images is https://github.com/test-org-dm/docker-mailserver/blob/gh-workflows/.github/workflows/build_docker.yml

It uses pre-defined actions with those it checks out the repository, set's up docker qemu for buildx and also uses a pre-defined action to build the image(s) and push them. What needs to be done is parsing of the branches, tags and pull requests to properly tag the docker images - together with proper sanity checking, etc. I assume proper automated checks could also be integrated.

Once you pushed to the repository or branch you can then check the progress in the "Actions" tab on the repository page - can you see them, too?

Regards
Andreas

[aendeavor]

Thanks for the invitation. Yes, I can see the actions.

Now that I've seen it, it could very well be the case that arm64 is the same as arm/v8.

There are two more things I'd like to ask:

1. Can you somehow grant me more privileges in the organization? As of now, I'm only a member but I cannot do anything:)
2. Is the repository somehow not public? I can't see the issues page. What's up with that?

[andreasfaerber]

Looks like the access system is far from being simple. ;-) I _think_ i have now allowed the administrators group full access to the repository. I have also added @radicand to the adminstrators team. The issue tab was disabled in the settings, i have now enabled it and it should be visible. You should be able to do everything with the repository now - at least if i am not mistaken. Please have a look and let me know.

[andreasfaerber]

Ok, i also found the setting to make you owner of the organization, too. From my perspective you should have full control over the organization and not only on the repository.

[aendeavor]

Works like a charm. I've opened an issue in your repo about the tests so we can now work from there for the moment.

[aendeavor]

I can confirm that administrators / owners have access to the secrets, so collaborators can modify what is currently blocked, if needed. Therefore, the solution with GH Organizations / Actions seems perfect.

We now "only" need a scheduled build as well as test integration. Thereafter, we can finally decide what to do with this repository.

[wernerfred]

Hey - as the project brought me much value in the past i would like to give sth back. GitHub Actions is a thing i played a lot in the past few month. I could definitly support here if needed.

What needs to be done is parsing of the branches, tags and pull requests to properly tag the docker images - together with proper sanity checking, etc. I assume proper automated checks could also be integrated.

Here for example we should have a look at this action for proper tagging and labeling of docker images.

Also we might have a look at the github built-in depandabot feature and a Dockerfile linter like hadolint.

Hit me up if there are open tasks and i will see what I can do.

[aendeavor]

That's awesome to hear @wernerfred.

@andreasfaerber has posted some links about the test project we are working on. Feel free to participate there as we are now working over there. Open tasks are actually exactly what you mentioned: Parsing and labelling. There is currently a WIP PR for test suite integration. We'd need one for parsing as well.

Since you mentioned you've gained experience with Actions, I would really like to see some kind of overview, how our actions should work together, for example with a diagram or a textual description. Because we need to make sure certain steps are only done when others succeeded prior (Lintint / Testint -> Building -> Pushing | on what events, pushes, PRs, branches, etc.), in order to achieve a clear structure. That would be awesome.

You also mentioned Hadolint. We are already linting against Hadolint:)

You mentioned Dependabot. I've read a bit about it - if you'd like to add this, feel free to open a PR on @andreasfaerber's test repo.

[aendeavor]

As there are some new ideas and more work that originally planned, I've updated the issue description, especially the task tracking section and introduced a tier list. Tier one has the highest priority.

For anyone who'd like to contribute, feel free to help with one of the open tasks. Work is done and issues are created on @andreasfaerber's test repo.

[williamdes]

I did TLRD this thread and will maybe read it another time.

Transferring the main development repository to someone else, preferably a (somewhat active) maintainer.

I would propose to move this project to @code-lts that is specialised into long term maintenance of projects.

[erik-wramner]

Personally I'd rather create a new organization specifically for docker-mailserver (named docker-mailserver) unless code-lts adds something new to the picture. The name is also a bit confusing because we make no LTS guarantees as such.

Great work here, seems to be shaping up. However, I still feel it would be great with some quick thoughts from @tomav?

[aendeavor]

The implementation of the GH Actions workflow in test-org-dm/docker-mailserver#2 seems to be very close to being finished. All tier 1 goals of this issue are thereby fulfilled. Here's my proposal for migrating this repository:

I'm with @erik-wramner on creating a new organization specifically for docker-mailserver. I'd be _very_ glad if @tomav could then migrate this repository to the new organization. But in case there's no response, we will need to fork this repository and work with the new fork. In the second case, I would issue a deprecation notice in this repository's readme, and we begin a soft migration period. We try to close off all issues here, and new issues shall be created in the new repo. Same goes for PRs. I think we should be able to rebase the new repo if the left-over PRs from this repo are merged.

---

I'm already working on the migration in https://github.com/docker-mailserver/docker-mailserver/issues/2.