stalwart: Change maintainer

[docjyJ]

I see %AIO_CHANNEL%, is it working for AIO community containers ?

[szaimen]

I think this would not work

Actually it would but it requires all "normal" aio tags also to be existing for https://hub.docker.com/r/marcoambrosini/aio-stalwart/tags. So at least latest, beta and dev. So you will at least need to mantain all these tags in parallel if you want to do so.

Also you will sooner or later definitely run into this: https://github.com/nextcloud/all-in-one/discussions/4784#discussioncomment-9712152

[docjyJ]

Actually it would but it requires all "normal" aio tags also to be existing for https://hub.docker.com/r/marcoambrosini/aio-stalwart/tags. So at least latest, beta and dev. So you will at least need to mantain all these tags in parallel if you want to do so.

It's not necessary to maintain 3 tags. All 3 tags can point to the same container.

When upgrading, simply point the beta to the new container, and all beta users will receive the update without having to wait for an AIO beta.

And to release to all users, there's no need to be rushed by AIO beta deadlines.

Also you will sooner or later definitely run into this: https://github.com/nextcloud/all-in-one/discussions/4784#discussioncomment-9712152

For changes requiring json modification, you'll always have to go through JSON modification...

It would be really nice to have a solution for free version testing.

[szaimen]

Actually it would but it requires all "normal" aio tags also to be existing for https://hub.docker.com/r/marcoambrosini/aio-stalwart/tags. So at least latest, beta and dev. So you will at least need to mantain all these tags in parallel if you want to do so.

It's not necessary to maintain 3 tags. All 3 tags can point to the same container.

When upgrading, simply point the beta to the new container, and all beta users will receive the update without having to wait for an AIO beta.

And to release to all users, there's no need to be rushed by AIO beta deadlines.

I am fine with this change honestly but it gets more complicated for its maintainer imho...

Also you will sooner or later definitely run into this: #4784 (reply in thread)

For changes requiring json modification, you'll always have to go through JSON modification...

It would be really nice to have a solution for free version testing.

So what would be your suggestion?

[docjyJ]

V2.%AIO_CHANNEL% should work. In the case of complex changes (port, env...) adding a VX prefix would ensure that the correct volumes are mounted, etc.

I don't think it will be any more difficult.

With Github Repository and Github Actions, everything can be automated.

[szaimen]

V2.%AIO_CHANNEL% should work.

I fear this is going to break. See https://github.com/search?q=repo%3Anextcloud%2Fall-in-one%20AIO_CHANNEL&type=code. So in that case we would need to update the logic internally in order to allow for something like that.

[docjyJ]

Exemple of workflow :

name: Create and publish a Docker image

on:
  push:
    branches: 
      - 'latest'
      - 'beta'
      - 'dev'

env:
  aio_tag: v1-{{branch}}

jobs:
  build-and-push-image:
    name: Build and Push Docker image to GitHub Container Registry
    runs-on: ubuntu-latest

    permissions:
      contents: read
      packages: write
      attestations: write
      id-token: write

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Extract metadata (tags, labels) for Docker
        id: meta -V1
        uses: docker/metadata-action@v5
        with:
          images: ghcr.io/${{ github.repository }}
          tags: ${{ aio_tag }}

      - name: Log in to the GitHub Container Registry
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Extract metadata (tags, labels) for Docker
        id: meta
        uses: docker/metadata-action@v5
        with:

      - name: Build and push Docker images
        id: push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}

      - name: Generate artifact attestation
        uses: actions/attest-build-provenance@v1
        with:
          subject-name: ghcr.io/${{ github.repository }}
          subject-digest: ${{ steps.push.outputs.digest }}
          push-to-registry: true

• Push to dev automatic update dev docker image.
• Then merge dev into beta to test with nc beta.
• Then beta into latest to release.

When change volume port and other breaking :

• Change, rename tag v1-{{branch}} to v2-{{branch}}.
• Propagate dev -> beta -> latest.
• Update v1-%AIO_CHANNEL% to v2-%AIO_CHANNEL% in AIO json.
• Wait AIO beta and rollback if doesn't work.

It's can't be easier... 😅

[docjyJ]

V2.%AIO_CHANNEL% should work.

I fear this is going to break. See https://github.com/search?q=repo%3Anextcloud%2Fall-in-one%20AIO_CHANNEL&type=code. So in that case we would need to update the logic internally in order to allow for something like that.

Yes I think it's doesn't work...

[szaimen]

V2.%AIO_CHANNEL% should work.

I fear this is going to break. See https://github.com/search?q=repo%3Anextcloud%2Fall-in-one%20AIO_CHANNEL&type=code. So in that case we would need to update the logic internally in order to allow for something like that.

Yes I think it's doesn't work...

so this would need to be adjusted first

[szaimen]

on:
  push:
    branches: 
      - 'latest'
      - 'beta'
      - 'dev'

I made a mistake, instead of dev, the correct one is develop

[docjyJ]

V2.%AIO_CHANNEL% should work.

I fear this is going to break. See https://github.com/search?q=repo%3Anextcloud%2Fall-in-one%20AIO_CHANNEL&type=code. So in that case we would need to update the logic internally in order to allow for something like that.

Yes I think it's doesn't work...

so this would need to be adjusted first

If you think it's a good idea, I'll try to implement it.

[szaimen]

V2.%AIO_CHANNEL% should work.

I fear this is going to break. See https://github.com/search?q=repo%3Anextcloud%2Fall-in-one%20AIO_CHANNEL&type=code. So in that case we would need to update the logic internally in order to allow for something like that.

Yes I think it's doesn't work...

so this would need to be adjusted first

If you think it's a good idea, I'll try to implement it.

I don't think it is necessarily a good idea but I get the need from your side for such a feature. That is why I would be fine if you go ahead implementing this.

[docjyJ]

I use all aio branch.

[docjyJ]

I prefer to keep things as simple as possible, to avoid introducing bugs.

I will see about publishing on Docker Hub.

And I used the 3 channels, the Stalwart mail server is starting to become serious. Port and volume should not change.

For environment variables I can simply duplicate them (eg: if the MY_ENV variable has a new schema, I create MY_ENV_2 to ensure compatibility, and I possibly correct the rename in the script or config).

I think a lot of people would like a mail server associated with AIO. I would really like to provide stability. (And I would like to migrate my own config to integrate it into the backup)

[docjyJ]

DockerHub done: https://hub.docker.com/r/docjyj/aio-stalwart/tags

[szaimen]

This is now released with v9.1.0 Beta. Testing and feedback is welcome! See https://github.com/nextcloud/all-in-one#how-to-switch-the-channel

[docjyJ]

Tested locally. Admin login and WebUI work !