Rofl public vars

[martintomazic]

Part of oasisprotocol/oasis-sdk#2248.

Used public var instead of env to make sure people don't accidentally set secrets here.

Tested it with https://github.com/oasisprotocol/Honoroll/pull/440.

[netlify]

✅ Deploy Preview for oasisprotocol-cli canceled.

Name	Link
🔨 Latest commit	813ada8
🔍 Latest deploy log	https://app.netlify.com/projects/oasisprotocol-cli/deploys/6a4d60348bbf840008a3814d

[martintomazic]

Followed the style and organisation 1:1 with oasis rofl secrets.

[martintomazic]

NIT: existing global config makes things hard to test cleanly :((

[matevz]

If you define a public var with the same name as the existing secret, Oasis CLI should fail.

[martintomazic]

If you define a public var with the same name as the existing secret, Oasis CLI should fail.

Private variable name (if --public-name is set) is available inside rofl.yaml so the fix should work in all cases...? Writing tests for the new validation would require a thorough refactor of the existing code, so I only tested manually for now.

Note there is similar issue with secrets definitions overlapping between each other:

the secret name is capitalized and spaces are replaced with underscores, so a secret called my secret will be available as MY_SECRET.

meaning cli should probably not allow setting my secret and MY_SECRET at the same time as a rofl secret, but I would ignore this as 1. existing and 2. app admin should be responsible.

[matevz]

Please also mention special env. metadata fields behavior in the ROFL manifest specs https://github.com/oasisprotocol/oasis-sdk/blob/main/docs/rofl/features/manifest.md

[matevz]

It would be useful to have another rofl public-var set-env-file <dot-env-file> command which references the given .env filename with the current deployment.

Then, ROFL manifest file is updated with something like

deployments:
  testnet:
    metadata_env_file: .env.testnet

And when you run oasis rofl update, the content of this env file is read on-the-fly and populates env. fields in metadata. This way we never get inconsistency between .env files and the manifest.

[martintomazic]

I assume rofl github actions will have access to env files as they run in the repo checkout or?

My concerns are:

1. What happens if you have variables defined both as part of the manifest metadata and inside manifest referenced env file? What happens if they overlap? Do we want precedence complexity?
2. Currently manifest acts as a source of truth for other commands, so every time manifest.GetMetadata() is called we will have to parse it add hoc into the same structure that will differ in memory to what is persisted? What happens when we later write the manifest back? Or we introduce overlay concept, that other commands need to learn about (complexity).
3. Now before running oasis rofl update you will have two sources of truth that you need to mentally merge.
4. Not all metadata is meant to act as public config to docker containers (only .env prefix).

Locally forgetting to run oasis rofl public-var import is same as forgetting to write oasis rofl update?

For the CI I would prefer to run a simple validation step, e.g. running oasis rofl public-var import .env.testnet --force should produce an empty diff for the CI to pass. This way you have sync guarantee without adding further complexity to the cli/manifest parsing?

[martintomazic]

Even better inside make/just file we add a command for sanity/sync validation, which can then be called locally (if deploying from local machine) or inside CI.

[peternose]

Please also mention special env. metadata fields behavior in the ROFL manifest specs https://github.com/oasisprotocol/oasis-sdk/blob/main/docs/rofl/features/manifest.md

You could also gather these variables under the same key, e.g. metadata["env"] = "city=London,country=England".