support default config file overrides #14090
Conversation
|
I see you updated files related to
|
| Chain | ||
| }{} | ||
|
|
||
| if err := cconfig.DecodeTOML(bytes.NewReader(b), &config); err != nil { |
There was a problem hiding this comment.
Correct me if I'm wrong but these overrides are specified at runtime it seems? We're not statically embedding the overrides depending on a particular env var (seems hard / impossible now that I think about it since go:embed is on file level vars
There was a problem hiding this comment.
Does this imply that these defaults need to be manually shipped to nops separately if they're not embedded in the built binary?
There was a problem hiding this comment.
Yes but only if not using the official docker release which can bundle them in.
There was a problem hiding this comment.
I agree w/ @jmank88 - The easiest CX I can imagine for the NOPs is including the overrides directory and the env var in the docker image. That way they won't have to think about this at all.
It will take some time before CCIP doesn't release its own image, so this approach seems the easiest from a release perspective as well to me.
patrickhuie19
force-pushed
the
feature/bcf-3351
branch
from
484fec5 to
f90b635
Compare
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
… does not exist in the embedded defaults
patrickhuie19
force-pushed
the
feature/bcf-3351
branch
from
1c8fd7b to
e1d5521
Compare
|
The merge of the CCIP fork back into chainlink requires a feature to handle a difference in per chain defaults. Currently we have a directory of these defaults that is loaded through go:embed when the configuration for the application is created on
node startornode validate. CCIP has differing fields in these chain defaults (likeFinalityTagEnabled) that make it necessary to give an option to specify overrides on the current defaults.There were multiple ways of accomplishing this:
This approach uses an env var,
CL_CHAIN_DEFAULTSto specify when overrides should be applied, as I believed it most likely that the env (testcontainers, docker, k8s) the node is running in will be aware that the node needs to run CCIP jobs.This change is backwards compatible and can be fully tested through testscripts.