Add Lifecycle Configuration File #128
Conversation
In order to allow platforms to have more dynamic configurations, a new configuration file (`lifecycle.toml`) could be loaded by lifecycle binaries. Signed-off-by: Jesse Brown <jabrown85@gmail.com>
jabrown85
force-pushed
the
jab/add-lifecycle-config
branch
from
2011f1c to
dafa8f4
Compare
Signed-off-by: Jesse Brown <jabrown85@gmail.com>
jabrown85
force-pushed
the
jab/add-lifecycle-config
branch
from
2c7f858 to
7333346
Compare
|
|
||
| An example `lifecycle.toml` might be produced by the platform with various inputs (source code, platform specific configuration, etc.): | ||
| ``` | ||
| [config] |
There was a problem hiding this comment.
I wonder if we should try to keep these keys matching the lifecycle flags exactly. So:
appinstead ofapp_dirorderinstead oforder_path
OTOH, these more closely match the env vars
There was a problem hiding this comment.
I went ahead and changed the names to be kebab-case, but I kept them matching the env variants for now. I was thinking it might make sense to be able to set some things that maybe aren't available as flags in the future. Like CNB_REGISTRY_AUTH isn't a flag, but you still might want to do the work to get that auth setup in the same pod. Similarly, there may be things like lifecycle feature flags or version selection that could be useful to have here that is likely to be available as an env var but may not have a flag name.
Signed-off-by: Jesse Brown <jabrown85@gmail.com>
jabrown85
force-pushed
the
jab/add-lifecycle-config
branch
from
47a6a6e to
2d14c17
Compare
Signed-off-by: Jesse Brown <jabrown85@gmail.com>
jabrown85
force-pushed
the
jab/add-lifecycle-config
branch
from
4bd674c to
0bce3fd
Compare
| [alternatives]: #alternatives | ||
|
|
||
| - What other designs have been considered? | ||
| - Lifecycle could introduce a `prepare` phase that processes a project's `project.toml` to generate the input files needed by detector, much like `pack` does today. |
There was a problem hiding this comment.
does the implementation of prepare change anything for you here?
There was a problem hiding this comment.
If prepare outputs an order.toml and puts it in a location that detector picks up, I would be OK putting a pause on this RFC. That is my primary need right now.
| - What other designs have been considered? | ||
| - Lifecycle could introduce a `prepare` phase that processes a project's `project.toml` to generate the input files needed by detector, much like `pack` does today. | ||
| - Lifecycle could load env vars from a known file location. e.g. `source lifecycle.env` or similar prior to resolving lifecycle configuration. | ||
| - Lifecycle could only allow for non-path based inputs like `log-level` in `config.toml`, but add an additional path to to a known platform location. Example would be `/cnb/config/order.toml` for `CNB_ORDER_PATH`. This would allow platforms to use a volume at `/cnb/config` and write files that are fed into lifecycle in addition to a `config.toml` for non-path based configuration. |
There was a problem hiding this comment.
| - Lifecycle could only allow for non-path based inputs like `log-level` in `config.toml`, but add an additional path to to a known platform location. Example would be `/cnb/config/order.toml` for `CNB_ORDER_PATH`. This would allow platforms to use a volume at `/cnb/config` and write files that are fed into lifecycle in addition to a `config.toml` for non-path based configuration. | |
| - Lifecycle could only allow for non-path based inputs like `log-level` in `config.toml`, but add an additional path to a known platform location. Example would be `/cnb/config/order.toml` for `CNB_ORDER_PATH`. This would allow platforms to use a volume at `/cnb/config` and write files that are fed into lifecycle in addition to a `config.toml` for non-path based configuration. |
| # How it Works | ||
| [how-it-works]: #how-it-works | ||
|
|
||
| Lifecycle will read in `CNB_CONFIG_PATH` or the default of `/cnb/config.toml` and prioritize the values found over lifecycle's defaults and before present env vars. |
There was a problem hiding this comment.
What is the prioritization of the cli flag vs a configuration file?
I guess it is:
- cli flags
- env vars
- configuration file
- default
right? Maybe it's worth adding it.
** edit **
Now I see that it appears at the end of the "What it is" section.
Anyway, I think that it's worth adding the prioritization of the cli flags to this sentence.
| log-level = "debug" | ||
| ``` | ||
|
|
||
| An example config resolution would be, in prioritized order, CLI flag, os env `CNB_ORDER_PATH`, `[config.toml][config]order_path`, then the `lifecycle` default of `/cnb/order.toml`. |
There was a problem hiding this comment.
What about env vars that are also defined in the config file?
For example:
log-level = "debug" in the config file and EnvLogLevel as a variable that the user manually set.
|
I'm going to close this for now. This spec change will get me most of the way there by being able to optionally provide an |
Readable