Feature: fallback on environnement variables for strings parsing

[GlucNAc]

• Bug fix #…?
• New feature?
• BC breaks?
• Tests added?
• Docs added?

As I prefer yaml files for configuration, I have a made a little modification to make phpdeployer able to fallback on environnement variables when trying to parse a string, in order to get a clean yaml configuration file which can be standard across project, and gitlab-ci (and I think github actions too) compatible.

Given this yaml file and the corresponding environnement variables set into the CI/CD pipeline, everything should be fine 👍

config:
  application: '{{APP_NAME}}'
  release_name: '{{ARCHIVE_RELEASE_NAME}}'
  http_user: '{{HOST_HTTP_USER}}'
  keep_releases: 5
  writable_mode: 'chown'

hosts:
  staging:
    hostname: '{{STAGING_HOST}}'
    remote_user: '{{STAGING_REMOTE_USER}}'
    deploy_path: '~/{{application}}/{{alias}}'
  preprod:
    hostname: '{{PREPROD_HOST}}'
    remote_user: '{{PREPROD_REMOTE_USER}}'
    deploy_path: '~/{{application}}/{{alias}}'
  prod:
    hostname: '{{PROD_HOST}}'
    remote_user: '{{PROD_REMOTE_USER}}'
    deploy_path: '~/{{application}}/{{alias}}'

after:
  deploy:failed: 'deploy:unlock'

What do you think about?

[Schrank]

I like the idea, I'm curious how @antonmedv sees it :-)

[antonmedv]

What if we prefer all such vars with ENV_?

[Schrank]

You mean prefix? Instead of "auto discovery"?

[GlucNAc]

Actually I was thinking about how Symfony manage env vars, but phpdeployer is run on its own, so there is no need to take this consideration into account.

I have then done a push which use getenv method, like I've done here : #3421.

[GlucNAc]

What if we prefer all such vars with ENV_?

I guess you want to reduce the risk of regression? Actually, I've done another push to execute the fallback in "auto discovery" mode (like named it @Schrank) only if nothing else has worked (which is finally a true fallback compare to my first proposition).

In that way there is no regression possible as if the portion of code was missing, the script would lead to a blocking exception.

[GlucNAc]

Little up @Schrank @antonmedv :)

[GlucNAc]

Hi @Schrank @antonmedv, any news for this PR?

[antonmedv]

I don’t like what it’s for all the configurations. Let’s make it optional only in yaml via explicit exporfs.

[GlucNAc]

What do you mean by via explicit exporfs?

Actually, it would also be usefull for PHP configs too as in that way you don't need to edit your script to modulate its behavior and thus you can share your config across your projects. The way it is implemented is transparent for actual users who would upgrade to this version (because it is a fallback), but we can add a parameter to explicitly enable this feature to be sure to avoid any side effect (which can't occur because if you pass an unrecognised option, the deployment will fail by raising a fatal exception see

deployer/src/Configuration/Configuration.php

Line 111 in adbb4b7

throw new ConfigurationException("Config option \"$name\" does not exist.");

).

[GlucNAc]

@antonmedv @Schrank any update on this please ?