You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When running my application deploys, a lot of how they are configured depends on the target environment. For example, running MySQL locally I might only want to allocate 1GB of memory, but in production it would be much higher.
One of the ways I was thinking this could be possible, is if the service.yml allowed Jinja2 templating in the configuration values. This could be a powerful feature, especially if it were combined with a Jinja2 filter that allowed you to pull an environment variable. Imagine this:
But I think the self documenting nature of the first example, by being contained in service.yml, is more advantageous.
This would allow you to use a local .env file in development, with something like source .env && forge deploy. It would also be helpful for handling deploys in CI environments, without storing production values in the Git repository.
The text was updated successfully, but these errors were encountered:
the downside being that there's no list of environment variables available directly in the service.yml, which can just be managed by documenting them. this also feels less like you're setting defaults when editing service.yml, since it's not immediately clear that they could be overridden when viewing that file, so that might be confusing.
The Jinja2 templating in service.yml might be useful in other contexts, but would be unnecessary here.