-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BCF-2261] Break up config/v2 #9697
Conversation
I see that you haven't updated any CHANGELOG files. Would it make sense to do so? |
42de976
to
e22764a
Compare
core/utils/validate.go
Outdated
@@ -23,7 +21,7 @@ type Validated interface { | |||
|
|||
// Validate returns any errors from calling Validated.ValidateConfig on cfg and any nested types that implement Validated. | |||
func Validate(cfg interface{}) (err error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about a more specific name if this is going to live in a general utils package?
func Validate(cfg interface{}) (err error) { | |
func ValidateConfig(cfg interface{}) (err error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If anything, I would suggest making it less, rather than more, specific. That way this can be used generally to validate any struct.
eg.
func Validate(s interface{}) error {
...
}
type Validated interface {
IsValid() error
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But isn't the code hyper-specific to toml config? I'm concerned about moving any pieces over to utils:
Move config utilities relating to TOML, ValidateConfig, into utils.
It would not be appropriate to use most (all?) of these as-is from other parts of the system - TOML especially, since we use a different module here than for job specs, for example. I think they need to remain config scoped, at least by name, but package separation seems cleaner.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm... yes, fair point. How about a configutils package containing DecodeTOML, ValidateConfig and the various errors that might be emitted from ValidateConfig() functions?
What I want to achieve with this is to break the dependency between config/v2 and evmconfig/v2, since previously evmconfig/v2 would depend on config/v2, and this caused some import cycles, by moving the common parts out to a separate package.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, in the future LOOP Plugins will be responsible for validating their own config, so we will want to move these generic pieces over to chainlink-relay to be available for other repos. With that in mind, I think it would be simplest to keep a specialized package in the meantime.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm... yes, fair point. How about a configutils package containing DecodeTOML, ValidateConfig and the various errors that might be emitted from ValidateConfig() functions?
Yeah I think that would work 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a minimal package config
in chainlink-relay with copies of some error types:
https://github.com/smartcontractkit/chainlink-relay/tree/main/pkg/config
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Understood! Would you like me to move these pieces to chainlink-relay and import them here? Or should I just stick to putting them in configutils for now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think a local package is fine for now. We can move it later when we move the chain family types for LOOPs.
5427476
to
3486897
Compare
core/chains/cosmos/config.go
Outdated
@@ -17,37 +17,37 @@ import ( | |||
|
|||
"github.com/smartcontractkit/chainlink/v2/core/chains" | |||
"github.com/smartcontractkit/chainlink/v2/core/chains/cosmos/types" | |||
v2 "github.com/smartcontractkit/chainlink/v2/core/config/v2" | |||
"github.com/smartcontractkit/chainlink/v2/core/utils/configutils" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit/ I think it would be more idiomatic to name the package just config
to avoid repeating utils
:
"github.com/smartcontractkit/chainlink/v2/core/utils/configutils" | |
"github.com/smartcontractkit/chainlink/v2/core/utils/config" |
Can still name the imports when there are collisions 🤷
"github.com/smartcontractkit/chainlink/v2/core/utils/configutils" | |
configutils "github.com/smartcontractkit/chainlink/v2/core/utils/config" |
core/config/docs/docs.go
Outdated
@@ -38,12 +38,12 @@ var ( | |||
//go:embed example-secrets.toml | |||
exampleSecrets string | |||
|
|||
docsTOML = coreTOML + chainsEVMTOML + chainsCosmosTOML + chainsSolanaTOML + chainsStarknetTOML | |||
DocsTOML = CoreDefaultsTOML + chainsEVMTOML + chainsCosmosTOML + chainsSolanaTOML + chainsStarknetTOML |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any way to avoid exporting these vars? Ideally they would be co-located with their usage. IIRC there was an obstacle to using an internal/ directory when I first implemented this, but that may have changed.
eb283c4
to
2642950
Compare
2642950
to
71edd75
Compare
core/config/docs/defaults.go
Outdated
) | ||
|
||
func CoreDefaults() (c toml.Core) { | ||
if (defaults == toml.Core{}) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jmank88 Let me know what you think of this change; instinctively I think it's an anti-pattern to have packages implement init, so I made the instantiation of defaults
lazy. This shouldn't change any behaviour since CoreDefaults is still one of the very first calls made at startup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How is this an improvement over an init func? A sync.Once
would be more efficient than a mutex, but with the init you don't need to synchronize at all.
23ac82e
to
830e674
Compare
@jmank88 I've removed my changes to CoreDefault and added the init back in. Your comment about that seems to have disappeared, but my thinking here wasn't primarily about efficiency, it was primarily about the principle of least surprise and avoiding side effects when a package is imported. |
SonarQube Quality Gate |
This PR is a proposal to break up the config/v2 package. Before this PR, the package combined multiple responsibilities, namely:
This PR breaks up these responsibilities so that the config/v2 package (renamed config/toml) is only responsible for defining the structs for the non-chain-specific config.