Reading configuration

In order for sdk.Client to work, it needs to be configured. The configuration can be read from a file, environment variables, code options or a combination of these.

The precedence of the configuration sources is as follows (starting from the highest):

• Code options
• Environment variables
• Configuration file
• Default values

The following flowchart illustrates the process of reading the configuration:

flowchart TD
    subgraph s1[Read config file]
        direction LR
        As1{{Config file exists}} -- true --> Bs1(Read config file)
        As1 -- false --> Cs1(Create default config file)
        Cs1 --> Bs1
    end
    subgraph s2[Build config struct]
        direction LR
        As2{{Has ConfigOption}} -- not set --> Bs2{{Has env variable}}
        As2 -- set --> Fs2(Use value)
        Bs2 -- not set --> Cs2{{Has config file option}}
        Bs2 -- set --> Fs2
        Cs2 -- not set --> Ds2{{Has default value}}
        Cs2 -- set --> Fs2
        Ds2 -- not set --> Es2(No value)
        Ds2 -- set --> Fs2
    end
    A(Read config) --> B(Read config options defined in code)
    B --> C(Read env variables)
    C --> s1
    s1 --> s2 --> I(Return Config)

Testing code relying on nobl9-go

Checkout these instructions along with a working example for recommendations on mocking sdk.Client.

Repository structure

Public packages

1. sdk defines:

   • Client which exposes methods for interacting with different Nobl9 web APIs.
   • Methods for reading and managing Nobl9 configuration (including the config.toml file) used by tools such as sloctl or the SDK itself.
   • Methods for fetching and parsing Nobl9 configuration objects.

2. manifest holds definitions of all Nobl9 configuration objects, such as SLO or Project. It is divided into three package levels:

   └── manifest
       └── version (e.g. v1alpha)
           └── object (e.g. slo)
   

   • manifest defines general contracts and generic methods for all objects.
   • Version-specific packages, such as v1alpha, define version-specific APIs, functions and structures shared by multiple objects.
   • Object-specific packages, like slo, provide object definition for specific object versions.

Internal packages

1. tests contains the end-to-end tests code. These tests are run directly against a Nobl9 platform.
2. internal holds internal packages that are not meant to be exposed as part of the library's API.

Contributing

Checkout both contributing guidelines and development instructions.