Proposal: CLI command checking missing secrets against environments

[pksieminski]

General idea is to use this new command in GitHub Workflows, which would allow us to check PR before merge if all secrets for development and production environments are properly set in Encore.

Right now it is possible to get very late feedback loop if for example you set the secrets only on development environment and after some time you deploy to production, where it fails on deploy step.

With new command, which would list missing secrets & error if any is missing:
encore secret check [envs...]

Example usage:

encore secret check prod dev
Secret Key Production   Development 
MySecret   ✗                   ✓

Error: There is 1 secret missing.

[aneshas]

Hey, if this one is still up for grabs I would like to take it.

[aneshas]

Hey @pksieminski @eandre

Since secrets list already pretty much does everything listed here apart from reporting an error, I was wondering if it makes sense to instead add a flag to the list command eg:

list --compare-envs=prod,dev (or whatever flag name makes more sense eg. --report-inconsistent ...)

which would then additionally exit with an error.
I know it would not be as explicit as having a separate check command but just wanted to bring it up.

Let me know what you think.

[aneshas]

Actually, now looking at what you initially wrote:

General idea is to use this new command in GitHub Workflows, which would allow us to check PR before merge if all secrets for development and production environments are properly set in Encore.

Does it then even make sense to provide environments as arguments since judging by the requirement we always want to compare dev <-> prod environments ?

[eandre]

The desired behavior isn't really about comparing environments. It should accept a list of environment types and report whether any secret doesn't have a value for any of the provided environment types. (If no environment types are provided it would default to check all environment types)

[aneshas]

Ok makes sense, but still, the reason I am asking is as far as I know (correct me if I am wrong), currently there are only two environment types as defined here ?

So the only possible combination is dev prod ...

I get it if we want to cover future cases where we would have more environment types but I do hope you see my confusion?

Thanks

[eandre]

No, secrets can be configured for four different environment types (local, PR envs, dev, and prod). See https://encore.dev/docs/primitives/secrets

[aneshas]

Now it makes more sense ;)

[aneshas]

Hey, I submitted a PR

[aneshas]

Hey, just wanted to follow up - are we gonna move forward with this?