On production I had removed the user patches lines to insert the following lines

I am starting to think that only adding ENVs like DOVECOT_ITERATE_ATTRS may not be enougth to have the magic work. Maybe default values in this file are an essential part too

What is not working for you?

You just want the test-cases you added to pass with the expected output correct? I'll ensure that happens 👍

for reasons that I ignore, this does not seem to give the options to the container creation process

Any help would be very welcome 🙏🏻

You will need to provide the array CUSTOM_SETUP_ARGUMENTS on container startup to the function that creates the container. Functions like _run_in_container do not take it into account.

If you want to have it added to the ENV of the container, you'll need to do so at the top of the file where the container is created I guess (or wherever it is created). Probably

https://github.com/docker-mailserver/docker-mailserver/pull/3426/files#diff-664e916443d73f328b2c0c61c3a1aca1de5b968cfb03316012765971cbb5980bR79

and

https://github.com/docker-mailserver/docker-mailserver/pull/3426/files#diff-664e916443d73f328b2c0c61c3a1aca1de5b968cfb03316012765971cbb5980bR93

Yeah, we need to create a new container instance when we want to use different ENV like your test-cases do.

I've converted the test file into the new format we use, but it is the kind that sets all containers up in the main setup() method, whereas you'll see some other tests elsewhere like hostname.bats needs to run different variations for different test cases so each test-case is making it's own container instance, and calling many functions as "test-cases" (a workaround I opted for).

We could technically have multiple .bats files instead, but for such small test-cases like yours that seems unnecessary. I will adapt this LDAP test to support both approaches, but the main annoyance I had was with the ENV setup / sharing.

Technically you could right now define a common base ENV and combine like done here:

Then you can create a container with different ENV like this small test-case:

You'd just expand an array like in the prior snippet I showed for sharing the base ENV each container is needing. Do note that you don't have to call it CUSTOM_SETUP_ARGUMENTS (although you should when you can), we just have to match the string value of the variable name that is passed to _common_container_setup().

Plan is that after converting all tests to the new format, to do another pass that moves to compose.yaml, which may instead rely on ENV files or a different way to modularize these config variants.

Also note that a PR is about to get merged which changes the test uniqueIdentifier to userID (uid).

Although my goal is iterating towards mail attribute, at least as the login name but presently the test and DMS are not properly configured for this, hence why your PR is delayed. I'd like to get that transition for our LDAP tests and docs addressed first, but am happy to go ahead with this Dovecot support for v13 after I can be more confident in our LDAP support and test coverage :)

Here's an example of what this would look like from the advice given in my review feedback:

@test "dovecot: (ENV DOVECOT_ITERATE_FILTER=(objectClass=PostfixBookMailAccount)) ldap email listing works" {
  # Container setup:
  export CONTAINER_NAME='dms-test_ldap_dovecot-iter3'
  local CONTAINER_ARGS_ENV_CUSTOM=(
    "${CONFIG_CONTAINER_BASE[@]}"
    --env DOVECOT_ITERATE_FILTER='(objectClass=PostfixBookMailAccount)'
  )
  _init_with_defaults
  _common_container_setup 'CONTAINER_ARGS_ENV_CUSTOM'

  # Actual test-case:
  _run_in_container doveadm user '*'
  assert_success
  assert_line --index 0 '[email protected]'
  assert_line --index 1 '[email protected]'
  assert_line --index 2 '[email protected]'
  _should_output_number_of_lines 3

  # Cleanup, removes test-case container:
  _default_teardown
}

The cleanup is just force removing the container:

Setup is like we do in setup(), except we need to export the custom args as a common base var to expand / import here. It's important to give each container a unique name to identify it, I chose to use the name variant dovecot-iter3 as it's the 3rd test-case container for testing against that ENV (or 2nd if we don't create a separate container for the default test).

Setting the name will ensure the helper methods used will know which container to use implicitly.