@perry This seems like a major shortcoming. I know I can use environment variables set in the UI – but that doesn’t answer my use case (or that of the OP) – because I can’t set the build context as an environment variable.
So, I have what seems like an extremely common use case: I have an ecommerce site, and the purchasing is handled via functions. What I want to do is use sandbox Stripe key/secrets for Pull Requests, and use the real, production key/secret in the production build.
Right now, the only way to do this is to base64-decode the context.clientContext.netlify. This feels really hacky, and I feel unsure if I can rely on it going forward.
In this thread: Figuring out if netlify-function is in a main env or production deploy - #2 by fool @Fool says that “we really should inject $CONTEXT”, and @futuregerald recommends “interpolating” from the base64 string.
At the very least the part of your documentation where you say “all these variables are available during your build” should have a BIG notice that says “but are NOT available to your functions”.
Is there an engineering challenge to injecting more contextual information either via process.env or the context.clientContext? Is this a feature that could be fast-tracked? Or at least could we get an assurance that if we start relying on base64-decoding the clientContext.netlify var that it will not change in the future?
Really appreciate any insight. I LOVE LOVE LOVE netlify, this just seems like a really common use case and a big shortcoming that might be easy to remedy. Thanks for listening!