Using $ENV in run-exec config

[blueblakk]

Is it possible to do something like the following, where the placeholder would be replaced with the hardcoded value when installing the hooks? I tried it, but it stays the same once the hook files are created.

"config": {
    "run-mode": "docker",
    "run-exec": "docker compose -p {$ENV|value-of:DOCKER_PROJECT_NAME} run --rm -T php"
}

[sebastianfeldmann]

Currently it's not.
What's the idea behind this? Since captainhook.json is configured per project you could hardcode this.
Or are you thinking about use the same a hook config in multiple projects?

[blueblakk]

I have a makefile with all my project docker compose build commands and since I'm using a custom docker compose project name I hardcoded it at first in my makefile, but since it needs to be customizable I added an env variable to my .env file and so I then also needed a way to refer to this variable in the captainhook.json config, it's also easily overlooked.

[sebastianfeldmann]

This is a bit more tricky than I thought. Currently placeholder only work in Actions and they are computed at runtime.
To use something like .ENV vars as replacement in any config value it gets a bit more tricky.

My idea for now is something like the following:

1. Allow custom placeholder registration
2. Use the placeholder in specific places in the configuration (not sure what those should be yet)

{
    "config": {
        "placeholder": [
            {
                 "trigger": "dotenv",
                 "class": "\\My\\Custom\\DotEnvPlaceholder",
                 "options": {"file": "./.env"}
            }
        ],
        "run-exec": "docker exec -i {$DOTENV|value-of:project_name}"
    }
}

The other solution could be to include a .env placeholder into the Cap'n but then the next week somebody has another cute placeholder idea and then the next week another ...

By allowing the registration and injecting of your own placeholders that makes it a bit more complicated but also a bit more flexible.

At the moment I'm not sure about the scope of the replacements. Should every config value be able to handle placeholders or only specific ones.

I think I'll make some performance check what it would mean to check for placeholders in every single config value and then make a final decision.