Skip to content

Conversation

@graham-chainlink
Copy link
Collaborator

Instead of using string , we use enum to represent the location of the datastore data.

Also exposes the location in the field of the Config struct so it can be used to select the right client to load.

JIRA: https://smartcontract-it.atlassian.net/browse/CLD-781

@changeset-bot
Copy link

changeset-bot bot commented Oct 24, 2025

🦋 Changeset detected

Latest commit: 6405ee0

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
chainlink-deployments-framework Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Instead of using string , we use enum to represent the location of the datastore data.

Also exposes the location in the field of the Config struct so it can be used to selec the right client to load.
@graham-chainlink graham-chainlink force-pushed the ggoh/cld-781/datastore-enum branch from d2c0f8c to 6405ee0 Compare October 24, 2025 03:42
@graham-chainlink graham-chainlink changed the title [CLD-781]: fix(datstore): change datastore location type to enum [CLD-781]: fix(datstore): change datastore type to enum Oct 24, 2025
Jira *cfgjira.Config

// DatastoreType specifies the type of datastore to use (either "file" or "catalog").
DatastoreType cfgdomain.DatastoreType
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will be used in Load Environment to load the right data from the selected datastore

@graham-chainlink graham-chainlink marked this pull request as ready for review October 24, 2025 03:43
@graham-chainlink graham-chainlink requested a review from a team as a code owner October 24, 2025 03:43
@Copilot Copilot AI review requested due to automatic review settings October 24, 2025 03:43
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR refactors the datastore configuration from a string type to a strongly-typed enum (DatastoreType), improving type safety and code clarity. The change introduces DatastoreTypeFile and DatastoreTypeCatalog constants and exposes the datastore type in the Config struct for downstream use.

Key Changes:

  • Introduced DatastoreType enum with validation methods to replace string-based datastore representation
  • Added LoadDatastoreType function to retrieve datastore configuration from domain files
  • Exposed DatastoreType field in the main Config struct for client selection

Reviewed Changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.

Show a summary per file
File Description
engine/cld/config/domain/domain.go Defines DatastoreType enum with constants, validation methods, and updates Environment struct to use the new type
engine/cld/config/domain/domain_test.go Updates tests to use DatastoreType enum constants instead of string literals
engine/cld/config/env.go Adds LoadDatastoreType function to load and extract datastore configuration
engine/cld/config/env_test.go Adds comprehensive test coverage for LoadDatastoreType function
engine/cld/config/config.go Updates Config struct to include DatastoreType field and loads it during initialization
engine/cld/config/config_test.go Adds assertion to verify DatastoreType is loaded in configuration
.changeset/good-chairs-allow.md Documents the change in the changeset

Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.

@cl-sonarqube-production
Copy link

for name, env := range cfg.Environments {
if env.Datastore == "" {
env.Datastore = "file" // Default to file if not specified
env.Datastore = DatastoreTypeFile // Default to file if not specified
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not 100% convinced on implicitly defaulting to DatastoreTypeFile inside the code as it seems too much hidden from the user. I'd prefer to always have an explicit setting in domain.yaml. Keeping it in the code for now is ok because we can release without problems but I'd add a TODO to remove that and always require a config once we add a domain.yaml config for all domain environments. Thoughts?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah i was thinking to maintain backwards compatibility for now, once once everyone is moved to catalog, we can enforce the config i guess. I added a todo for now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants