Turn off previews for specific PRs
complete
D
David Mauskop
Some PRs don't need a preview. It'd be nice if I could indicate this by putting something like
[skip preview]
or [preview skip]
in the PR title or description.Log In
Stephen Barlow
complete
You can now skip creating preview instances for a particular PR. To do so, include any of the following strings in your PR's title (not in a commit message):
- [skip render]
- [skip preview]
- [render skip]
- [preview skip]
This works for skipping standard PR previews, along with preview _environments_.
Stephen Barlow
complete
You can now skip creating preview instances for a particular PR. To do so, include any of the following strings in your PR's title (not in a commit message):
- [skip render]
- [skip preview]
- [render skip]
- [preview skip]
This works for skipping standard PR previews, along with preview _environments_.
Stephen Barlow
Created a new request to track allowing opting _in_ to previews per-PR, to supplement the current behavior of opting _out_: https://feedback.render.com/features/p/allow-opting-in-to-previews-per-pull-request-instead-of-opting-out
J
Julian Vergel de Dios
+1 on this, one way I thought of that might be useful to us would be to specify a matching pattern for the branch name. For example to only spin up previews for branches with the prefix
feature
or bugfix
.N
Nate Matykiewicz
I agree that I'd prefer to opt-in to a Preview Environment, vs opt out. As others have said, the vast majority of PRs don't actually need an environment. Also, PRs often get created before they're fully ready to demo. An easy way to turn the preview on when ready / wanted would be nice. We definitely don't want them for every PR the second the PR is made.
i
iain
This feels like something that could be achieved with build filters, if build filters were extended to support PR previews. I've raised a separate request for that because I don't think it would solve the problem for everyone
S
Steven Edouard
+1. I'm seeing our infrastructure costs nearly double because every PR has a preview. But only about 10-20% really need them. So it is a huge waste.
D
Dylan Colaço
I agree with the overall sentiment, feature previews for PRs is great, but realistically only about 10% of PRs need it. It would be great to control that with a label on the PR. Spinning up resources for every PR is a waste of time, money and consequently adding more CO2 into the atmosphere and accelerating climate change. There is no good reason to not implement this! At some point the cost-benefit is going to make people switch from Render to AWS/GCP much sooner than they would have
H
Hanna Lee
Echoing what others are saying - it is important that we are able to selectively indicate which PRs should be previews to reduce wasted build and service minutes. My personal preference is that I'd like to see it done in a way where I can add a label to my PR to trigger the preview environment to build, so it's opt-in and not opt-out. But even if it were opt-out like the suggestion to include some special trigger language in the PR description, that would be good too.
S
Sebastian Riddle
Any updates on this?
j
jason
Now that we're going to be charged for build minutes, I'd _really_ like to be able to disable preview environments for our PRs that only update our readme or other docs. This has been marked as planned for 2 years now, and I hope it can be finished soon.
B
Bart Van Remortele
I was looking into render as it looks like an interesting solution for our preview environment needs. This one is preventing us from using it however. It would make more sense if we could control this ourselves through a github action. Only deploy on label, destroy when label is removed.
Load More
→