Unable to add "--import-realm" to import embedded realm files

[yentlprojects]

I am using a custom build keycloak image that we use for our local development, but also during unit testing. This docker image contains a realm-export.json file inside the /opt/keycloak/data/import folder that I would like to be picked up during start-up of the testcontainer.

I've gone into the code and see that there are 2 configuration options:

public KeycloakContainer withRealmImportFile(String importFile) {
    this.importFiles.add(importFile);
    return self();
}

public KeycloakContainer withRealmImportFiles(String... files) {
    Arrays.stream(files).forEach(this::withRealmImportFile);
    return self();
}

which will later on be used in the configure method:

if (!importFiles.isEmpty()) {
    for (String importFile : importFiles) {
        // TODO: a strategy for files with the same name but in the different dirs
        String importFileInContainer = DEFAULT_REALM_IMPORT_FILES_LOCATION + FilenameUtils.getName(importFile);
        withCopyFileToContainer(MountableFile.forClasspathResource(importFile), importFileInContainer);
    }
    commandParts.add("--import-realm");
}

This requires you to explicitly define a realm file from your project however, and does not allow you to just enable the --import-realm trigger to pick up the already embedded realm file(s) inside of the keycloak image used.

Unless I'm missing something and there is in fact a way to do this, I would like to suggest to enable this possibility:

• Have an explicit boolean useRealmImport that can be set by a method on the KeycloakContainer class of the same name
• using the methods withRealmImportFile or withRealmImportFiles would also automatically set this new boolean flag
• In the configure method:
  • use this flag to call commandParts.add("--import-realm");
  • remove the commandParts.add("--import-realm"); from the existing !importFiles.isEmpty() if-conditional

I could make a PR for this if you agree.

[dasniko]

Hi, thanks for starting this discussion.
While I understand your need and the intention, I don't like implementing too much of single requested features. I'd like more to think about how we can achieve some similar behavior in opening the config options to do custom configs, without destroying too much existing features/functionality. E.g. in implementing some mechanism in the withCommand() methods where users can add custom configs, but have to do some additional work, so they know that they doing something not supported by the lib.

[yentlprojects]

Hi, thanks for your reply.

I thought this suggestion would be quite similar with how TLS is currently implemented (being that useTls() triggers a flag to be set, or the other methods that set additional config as well as this flag), and would also not break existing functionality.
Now if this way does not seem like the way to go for you, I would like to delve in deeper in the withCommand() method option.

Personally I would maybe find the use of withCommand() confusing, as that kind of sounds to me that that is the exact command you send to the container, but actually pretty much all other methods mutate what command will be used in the end (although I don't know much of other specific testcontainer implementations and the conventions on this)

I wonder if it would maybe be possible then to have a new, non-inherited method that allows to configure "addtional command parts", that in the configure method get merged together with the existing commandParts of

setCommand(commandParts.toArray(new String[0]));

(Assuming order never matters for the keycloak CLI)

So in total that would be something like:

private static final String[] additionalCommandParts = null;

public KeycloakContainer withAdditionalCommandParts(String... parts) {
    this.additionalCommandParts = parts;
}

@Override
protected void configure() {
    ...

    if (additionalCommandParts != null) {
        commandParts.addAll(Arrays.asList(additionalCommandParts));
    }
    
    setCommand(commandParts.toArray(new String[0]));
}

[dasniko]

Ah, yes, you are right, the withCommand method will set the given commands, not add additional ones. I didn't remember that properly.

[yentlprojects]

The current implementation (or lack of implemenation) is actually:

@Override
public KeycloakContainer withCommand(String cmd) {
    throw new IllegalStateException("You are trying to set custom container commands, which is currently not supported by this Testcontainer.");
}

I meant that if this method was to be used for the behavior described, I'd expect from the name that it would indeed set the given commands, rather than adding additional ones.

[yentlprojects]

Other suggestion to not change the API at all:

• don't assign importFiles = new HashSet<>(); in the constructor`
• In the following block, make sure to assign a new HashSet if importFiles == null:

    public KeycloakContainer withRealmImportFile(String importFile) {
        this.importFiles.add(importFile);
        return self();
    }

    public KeycloakContainer withRealmImportFiles(String... files) {
        Arrays.stream(files).forEach(this::withRealmImportFile);
        return self();
    }

• In configure, change !importFiles.isEmpty() --> importFiles != null:

        if (importFiles != null) {
            for (String importFile : importFiles) {
                // TODO: a strategy for files with the same name but in the different dirs
                String importFileInContainer = DEFAULT_REALM_IMPORT_FILES_LOCATION + FilenameUtils.getName(importFile);
                withCopyFileToContainer(MountableFile.forClasspathResource(importFile), importFileInContainer);
            }
            commandParts.add("--import-realm");
        }

Which then allows to perform a call to withRealmImportFiles with no params to enable the --import-realm flag