Can't modify max-allowed-packet

[rentalhost]

I am trying to use a different max-allowed-packet (currently is 16MB) on github worflow.

I have tried a lot of ways and nothing worked:

• Use as option --max-allowed-packet=... (unknown flag max-allowed-packet);
• Use as option --max_allowed_packet=... (unknown flagmax_allowed_packet);
• Link volume via mariadb_dir:/etc/mysql/conf.g (files named my.cnf or custom.cnf, options grouped by [mysqld], [mariadb], so on);

For some reason, I cannot set it anyway.

[rentalhost]

.github/workflows/build.yml:

    services:
      mariadb:
        image: ${{ matrix.databases }}
        ports:
          - 3306:3306
        volumes:
          - /.github/conf.d:/etc/mysql/conf.d
        env:
          MARIADB_USER: user
          MARIADB_ROOT_PASSWORD: password
          MARIADB_PASSWORD: password
          MARIADB_DATABASE: mariadb_alt
        options: >-
          --health-cmd="mariadb-admin ping"
          --health-interval=10s
          --health-timeout=5s
          --health-retries=3

.github/conf.d/custom.cnf:

[mysqld]
max_allowed_packet = 20M

But it still returning:

    console.log
      [ { Variable_name: 'max_allowed_packet', Value: '16777216' } ]

[grooverdan]

I am trying to use a different max-allowed-packet (currently is 16MB) on github worflow.

I have tried a lot of ways and nothing worked:

* Use as option [`--max-allowed-packet=...`](https://github.com/rheactor/mariadb-alt/actions/runs/4711323936/jobs/8355617023) (`unknown flag max-allowed-packet`);

* Use as option [`--max_allowed_packet=...`](https://github.com/rheactor/mariadb-alt/actions/runs/4711401710/jobs/8355751693) (`unknown flag_max_allowed_packet`);

The options in the yaml file is the option for docker. To pass as a option it needs to be passed as a command to the container, I think the github args: --max_allowed_package=20M might work.

* Link volume via `mariadb_dir:/etc/mysql/conf.d` (files named `my.cnf` or `custom.cnf`, options grouped by `[mysqld]`, `[mariadb]`, so on);

I think /.github/conf.d is read as a absolute path from root. Remove leading slash would be my assumption.

[rentalhost]

No luck...

The args method doesn't work because it's not supported by Github Workflow, and it looks like there's no way to add arguments at the end of docker create (and that would indeed solve 100%, but it's a feature that was suggested but not implemented yet). And even using options, the arguments are added in the middle of the command, breaking the behavior of docker create.

As for the volumes method, which I believe would be the ideal way to solve it, the problem is not in the slash, as that is supposedly how Github Workflows works (the slash would represent the root of the repository). On the other hand, even doing ls /etc/mysql/conf.d the custom.cnf file is not found inside the container. I don't know if the container deletes files during startup or something, and copying after checkout wouldn't work because the service would already be running with the initial settings.

[grooverdan]

On /etc/mysql/conf.d , I'd suspect its permissions. mariadbd starts as the mysql user within the container so global read access on files is needed.

[rentalhost]

I did not understand well. Is it something I can do on my side? From what I understand, the Github Workflow (service) is started before any step (when I could run some command). From everything I've read about volumes, it seems that the idea is precisely this: to prepare files to be used as soon as the container is ready, based on the files in the repository. But for some reason, it doesn't work at all. Maybe it's a Github Workflow limitation, but I couldn't find anything that pointed out this possibility either.

[rentalhost]

Ok, I finally make it work!

After having read https://github.com/orgs/community/discussions/42127 my suspicions became real: the Github Workflow service happens BEFORE the repository checkout. So when volumes is used and docker image is initialized, the repository data is still unavailable.

The way I did to resolve it was: perform the checkout step normally, copy the config file to the volume, and then restart the docker service. It's bad: the service needs to be restarted, but since it has just been "installed", the process happens practically immediately (less than 1 second).

    services:
      mariadb:
        image: mariadb:10.11
        # ...
        volumes:
          - ${{ github.workspace }}/build:/etc/mysql/conf.d

    steps:
      - uses: actions/checkout@v3

      - name: Copy MariaDB configurations
        run: sudo cp ${{ github.workspace }}/build/custom.cnf /etc/mysql/conf.d/custom.cnf

      - name: Restart MariaDB
        run: docker restart $(docker ps -q)

      # ...

On the other hand, someone suggested do something like Postgres did, but it must be done at the entrypoint. I didn't quite understand if that's it or how to do it, because it goes beyond my understanding, but maybe it would be something interesting to make these images compatible with Github Workflows and not need all that workaround that I had to do.

[grooverdan]

Ah, I seem to recall that from some point about the services before checkout. Nice workaround considering the limitations.

The only way an /docker-entrypoint-initdb.d might work is to create the configuration file in a /docker-entrypoint-initdb.d script as mariadbd restarts after init.

Until then, waiting on:

• https://github.com/actions/runner/issues/2139
• https://github.com/actions/runner/pull/1152 (possibly an out of date fix)