Custom environment templates

[ilnytskyi]

Warden allows to quickstart php environment.
But current stack is limited to built-in templates https://github.com/wardenenv/warden/tree/main/environments and images.
Although we can customize via .yaml overrides or use type local to have fully custom environment, it's not really portable solution.

What if we could install environment template from a git repo?

For example we create a new warden project and configure it like this:

WARDEN_ENV_NAME=symfony-custom
WARDEN_ENV_TEMPLATE=git@env-templates/symfony-custom#v0.2.0
TRAEFIK_DOMAIN=symfony-custom.test
TRAEFIK_SUBDOMAIN=app

the environment can even be versioned.

technically it would work the same way as now. All extension points would be preserved.

Warden would clone the template into local storage like $HOME/.warden/env-templates/<versioned-template>
Everything else would just work same.

• if template building a docker image - it's building it on host machine
• if template reuses prebuild image from registry - it pulls it

I'd summarize this feature as advanced and portable WARDEN_ENV_TYPE=local

Why not just commit .warden folder inside a repo?

• Well we can use WARDEN_WEB_ROOT=/source custom mount path. Hence one can have prebuilt environment for some framework without touching framework itself.
• Would fit a use case like this: https://github.com/orgs/wardenenv/discussions/937 where FrankenPHP support is requested. But now warden team must provide env template, images for different franken and php matrix versions, and instruction on how to use it, etc. With this feature all that - is the env-template's maintainer responsibility not Warden

My PoC

• I played around with warden using AI workflow and managed to get this working PoC:
  -- The Mage-OS cloned as is to ./sources
  -- The custom reusable template based on FrankenPHP classic mode and related services is used.

• The template is just usual custom warden-env.yaml

Open questions

0. Would anyone use this feature? Would it be useful to you?

1. How to make it more opinionated and play well with defaults and customizations?

For example the template may name some services different causing warden incompatibility. Like naming the shell or debug containers.
So project level override can be needed

WARDEN_ENV_SHELL_CONTAINER=franken-php
WARDEN_ENV_DEBUG_CONTAINER=franken-debug

2. Warden and template can evolve independently. The template can behave like a package that require min_warden_version >= 16

3. global vs project service boundary. Now we have warden spx or warden valkey or warden db global commands that only compatible with current environments. SPX cannot be used on a node.js project.
   Technically can be mapped to the template or exposed from it to the project globals

4. Any alternative approaches?

If enough feedback gathered and there are people willing to review and test it I can open PR with what I have now.

[bap14]

This seems to be inline with an existing discussion: https://github.com/orgs/wardenenv/discussions/793