Package filesystem implements a file system backend for the config client.
May be useful during local development.
A "Config Folder" has the following format:
Where `...` indicates any arbitrary path-to-a-file, and <brackets> indicate a single non-slash-containing filesystem path token. "services", "projects", ".json", and "refs" and slashes are all literal text.
This package allows two modes of operation ¶
Symlink Mode ¶
This mode allows you to simulate the evolution of multiple configuration versions during the duration of your test. Lay out your entire directory structure like:
- ./current -> ./v1
During the execution of your app, you can change ./current from v1 to v2 (or any other version), and that will be reflected in the config client's Revision field. That way you may "simulate" atomic changes in the configuration. You would pass the path to `current` as the basePath in the constructor of New.
Sloppy Version Mode ¶
The folder will be scanned each time a config file is accessed, and the Revision will be derived based on the current content of all config files. Some inconsistencies are possible if configs change during the directory rescan (thus "sloppiness" of this mode). This is good if you just want to be able to easily modify configs manually during the development without restarting the server or messing with symlinks.
This implementation is quite dumb, and will scan the entire directory each time configs are accessed, caching the whole thing in memory (content, hashes and metadata) and never cleaning it up. This means that if you keep editing the files, more and more stuff will accumulate in memory.
This section is empty.
This section is empty.
New returns an implementation of the config service which reads configuration from the local filesystem. `basePath` may be one of two things:
- A folder containing the following: ./services/servicename/... # service confinguations ./projects/projectname.json # project information configuration ./projects/projectname/... # project configurations ./projects/projectname/refs/refname/... # project ref configurations
- A symlink to a folder as organized above: -> /path/to/revision/folder
If a symlink is used, all Revision fields will be the 'revision' portion of that path. If a non-symlink path is isued, the Revision fields will be derived based on the contents of the files in the directory.
Any unrecognized paths will be ignored. If basePath is not a link-to-folder, and not a folder, this will panic.
Every read access will scan each revision exactly once. If you want to make changes, rename the folder and re-link it.