0verbyte / envmold Goto Github PK

The action should run the following tasks:

• golangci-lint
• Unit tests

After those are in place it would be nice to be able to automatically build a new mold release when a tag is pushed. Related (#6, #8)

Add secret_manager_vault.go, which should implement the SecretManager interface in secret_manager.go.

https://www.vaultproject.io/

Few notes:

• Vault testing should be available using a local Vault test server in Docker.
• The Vault server should have seeded values to be able to run integration tests against the Vault server.

Add a section to the README for how secret manager works.

This will make it easier to unit test mold.Generate since the input answer and values can be scripted.

https://github.com/goreleaser/goreleaser

The released binary should be able to run on Linux and MacOS.

The first version of the template file should have the ability for setting environment variables with a default value, specifying the environment variable type, and making the environment variable required or not. The following template is a simple format that will be implemented to handle these cases.

Template name as stored on the file system in the project: mold.yaml

File contents:

- name: string
  value: type
  type: string | boolean | number
  required: boolean

Environment variables are configured using an array of map types. Each map type field is described below. If maps with the same name field are specified, then the last instance is used in the order it was read from the file (top to bottom).

Fields
name - name of the environment variable. The type of name is a string
value - value of the environment variable. The type for value should match the type set in type.
type - type for the environment variable. The value set in the value field will be parsed to ensure the value's type is constrained to this type.
required - denotes whether the environment variable is required or not.

Logic

• Setting an empty value for the value field without the required field set will set the environment variable to an empty value. If the required field is set to true with the value field empty, the user will be prompted on the command line to provide a value for this environment variable.
• When required is set to true and value is set, then the user will be prompted with the current value and asked if they would like to override this value. If yes, then the user is given a prompt to set the value.
• Types set within the type field will be checked at runtime during parsing of the value field.

Add ability to import values from secret manager services, with the idea being you can import values from vault, or secrets manager, using the following syntax vault('my-secret') as the value in the mold template value field.

This should define a common interface to make it simple to create new importers. E.g.,

type SecretManager struct {
    Get(string) (string, error)
}

Additionally, there will need to be a config type for each underlying secret manager implementation. The configuration should hold information on how to connect to the respective secret service.

Tagging environment variables will allow the ability for environment variables matching the given tags to be written to the environment.

Add a new field to the template called tags that allows an array of tags to be defined.

- name: foo
  value: "bar"
  type: string
  required: false
  tags: ["dev", "local"]

Extend mold CLI to accept a new runtime flag called -tags, which accepts one or a comma delimited list of tags. This runtime CLI flag will allow the user to pass custom tags for filtering environment variables matching the same tag(s) to be written to the environment. Multiple tags will result in an OR expression to be used when filtering environment variables. If -tags is not present on the command line the default will be an empty array of tags, thus no filtering will be applied.

Unit tests will need to written to validate the tagging system and filtering works as expected.

Need a way to write environment variables from the mold template (#2) to different output systems. The output writer should be able to accept an interface with a Write method that each output type will need to implement. The Write method should take the parsed mold template as an argument.

The initial implementation should write environment variables to stdout.

Example output when writing to stdout.

export FOO="bar"
export DEBUG=1
export PRODUCTION=false

https://github.com/golangci/golangci-lint

Need to make sure that logging output is going to stderr. If log messages are going to stdout, then when using stdout as the output writer the output is invalid since the output will also contain log lines instead of only environment variable data.