How to add an app specific releases.exs configuration in umbrella project?

smon

I am currently writing my first umbrella project. One of my apps is an API and I use a basic releases.exs to set its HOST domain using an environment variable:

import Config

config :my_api,
  host_url: System.fetch_env!("HOST")

The downside: Now all other release builds expect a HOST variable, which is unnecessary. What is the recommended pattern for this? I want to enforce the check in my API app, so currently I just add an unused HOST variable for all the other apps.

Any suggestions?

6 comments

#umbrella #mix-releases #environment-variables

0 1976 6

2021-09-03 12:55:26 UTC

Showing Posts 1 to 6

Show Best Posts
Show All Posts (oldest first)
Show All Posts (newest first)

trisolaran

Hi @smon,

apps under an umbrella share the same configuration and releases.exs.

What is exactly the issue here? If I’m reading your code snippet correctly, host_url is part of the configuration of your my_api app, and other apps in the umbrella won’t even care.

Post #1

LostKobrakai

From the docs of mix release:

You can change the path to the runtime configuration file by setting :runtime_config_path inside each release configuration. This path is resolved at build time as the given configuration file is always copied to inside the release:
releases: [
  demo: [
    runtime_config_path: ...
  ]
]

You could therefore maintain multiple configs if one doesn’t suite your needs.

Post #2

smon

The release.exs gets incorporated into all builds. This results in a System.fetch_env!("HOST") call on startup/runtime for all apps and an exception for those apps where HOST is not set.

Post #3

smon

That’s it, thanks. But I need to rename my release.exs to something non-standard. Thanks!

Post #4

trisolaran

Thanks for the clarification.

My view is that if you need multiple apps that have to be started independently with different environments, then an umbrella app is probably not the right idea

I think there are different use cases for umbrella apps, but to me the typical one is when you have a number of apps depending on each other and that have to be started as a whole. In this case it makes sense and it’s more convenient to have a single configuration and a single environment to start the whole application bundle (by a similar token, when you install a hex package the application in the package also shares the same configuration with your main app).

Creating an umbrella app and then splitting the start-up and configuration logic feels like an anti-pattern to me - probably better to split the apps into multiple stand-alone ones which you can then start independently.

Post #5

smon

I get what you mean, maybe some background:

In my case the apps are closely coupled in the sense that, code wise, they are all using one central “core”-app that is also in the umbrella. I want to ensure that all apps are kept aligned with each other, running their tests on the same “core” app code.

Originally, I had only one app that managed everything (-> one single supervision tree). But I want the API app, for example, to run really stable, and be completely independent of data aggregators that harvest external resource over the net and are more prone to errors.

So I moved to an umbrella project (-> API has now its own supervision tree).

I could of course move further and split everything up into separate repositories, but then I have more hassle keeping everything aligned and tested. I’d rather have one separate runtime configuration for the time being.