Documentation
¶
Overview ¶
Package local reads configuration from the Valkey instance a local Celerity development session runs.
It is selected by importing it, which is how an application picks a platform without naming one anywhere else:
import _ "github.com/newstack-cloud/celerity-go-sdk/config/local"
An init registers it for the local platform, so `celerity dev` reaches the same store the other SDKs do. The generated platform file links it alongside whichever provider the deploy target needs, because a local session runs the artefact built for that target with CELERITY_PLATFORM set to local: an application does nothing to have configuration work in both.
What it reads ¶
One key per store, holding a JSON object of the values. That is what the Celerity CLI writes, and reading it any other way would make the tooling language-specific: the CLI populates one store for every SDK.
A separate module because it needs a Redis client, and an application deployed to a cloud should not carry one to reach a store it will never read.
Index ¶
Constants ¶
const ( HostEnvVar = "CELERITY_CONFIG_VALKEY_HOST" PortEnvVar = "CELERITY_CONFIG_VALKEY_PORT" )
Environment variables a local session sets, naming the Valkey it runs.
const Name = "local-valkey"
Name identifies this provider in errors.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type Provider ¶
type Provider struct {
// contains filtered or unexported fields
}
Provider reads configuration from a local session's Valkey.
An application does not construct one: importing this package registers it, and it is selected when the platform is local.
Source Files