Hello guys, I am Nam and this is my personal blog about my work, my life. Outside of work, I do something about UI, UX, DevOps, mobile...
Ever since Deploy Previews were first introduced by Netlify in 2016, users have been able to use them to see what the results of merging a pull request would be. They offer a valuable glimpse into the future and give insights and visibility to contributors and maintainers alike.
Making Deploy Previews and their corresponding build logs visible has proven to be popular and empowering. But what if a build uses environment variables which we'd rather not make public, like API keys or other secrets? If we're not careful someone could create a pull request which exposes our environment variables as part of an automated Deploy Preview. We'd rather not have that.
In projects with public repositories, Netlify offers control over how environment variable are handled in the automated builds triggered by pull requests from unrecognized authors. Or "untrusted deploys" as we call them. You can choose from the following options:
Deploy without sensitive variables - Untrusted deploys continue to build automatically, but any environments identified as being sensitive are omitted. You could either let your build continue without the features requiring the environment variables, or you could specify public fallback values thanks to deploy contexts and your netlify.toml configuration.
Require approval to deploy - Rather than automatically building all pull requests, sites can be configured to require approval from a team member before an untrusted deploy can continue.
Deploy without restrictions - If you are sure that your environment variables do not contain sensitive content, you can opt out of these controls and allow your site to automatically build Deploy Previews as normal.
In order to help you keep track of which environment variables, if any, were omitted from each build, we'll include such details in the deploy logs.
We'll also include the information that sensitive environment variable were omitted in your deploy notifications to help you keep aware of what is happening in your builds.
If you've not yet worked on a project which used Deploy Previews, you can see an example of how they surface in places like GitHub pull requests thanks to our deep integrations with git providers. Here's an example from the Yarn site.
We believe that enabling this type of visibility during the development and content authoring activities in web projects brings a huge boost in a productive and confident development pipeline.
If you have questions or suggestions about how we might continue to improve this powerful feature, join the conversation over in the Netlify Community