Build my own Deploy Previews

I’m not happy with what the build images allow me to do, unfortunately. That’s OK, it’s not the main reason I’m using Netlify, which is for the atomically deployed CDN capability, which is awesome. I know that it’s possible to manually upload a site that I’ve built separately, and that’s really cool.

Is it possible to manually upload deploy previews, or something sufficiently similar to them? They need to be separate temporary sites that are built for each pull request, but I’d like to do the actual building elsewhere. GitHub actions is where I’m currently thinking I’d like to do that. It would allow me to ensure that I have exactly the tools and versions I need to do my build.

I know that there are branch deploys, but I’m not sure that’s what I’m looking for. I’m looking for the dynamic sites nature of things, but I get the feeling from everything I read that they’re not really trying to solve the same problem. Is that a good understanding?

Sure, if you use the cli to deploy, it is by default in draft mode, which creates a browseable, stable URL like https://deploy-id-hash--sitename.netlify.com without updating your production URL.

You could alternatively use a second site for that purpose, so that you could browse it as yourtestsite.com rather than the per-deploy hash hostname.

1 Like

The deploy hash sounds pretty nice, thanks. I guess if I wanted to keep a stable URL per pull request, then I’d need to manage sites myself. That’s probably an alright thing to be doing, I was just wondering if there was a good way to hook into the existing deploy previews feature to make it a bit more seamless.

I haven’t used branch deploys yet, but I suspect that branch deploys might be similar. In my case all of our stuff is made in branches, so if I can manage branch sites through the API or something, and manually upload branch deploys, that would probably work well. Don’t know if that’s exposed.

Thanks for your insight. If you have answers to those questions, I’ll be happy to get them, but I appreciate the feedback you’ve given me already.

There is a more seamless way - let us build from git :slight_smile: But yes, deploy previews are specifically built from PR’s so you can’t make one like that yourself using the CLI. Branch deploys are the same thing - built from git based by us to be published at the stable URL.

Might be the case that our upcoming build architecture (see Discover | Netlify Integrations for some more details) would be flexible enough to allow you to use our builds - not sure, but probably worth looking into as managing more than a few such sites sounds like a pain to be avoided if possible :slight_smile:

I’m actually willing to do have you build for me, so that’s not off the table for me if we can get it working to my satisfaction.

Right now I’m trying to build some docs that are in the same repository as my code. Unfortunately, both build images are failing for me, and it seems to be over the Python version, though in different ways. There was some kind of an error with 2.7 on the older image, and the newer image complains that Python 3.8 is not available. I can work around things, as long as there’s not something throwing errors before I can even jump in to save it from itself.

The new plugins beta may be exactly what I need to figure out a solution to this issue. Watching the talk, I’m quite hopeful that I’ll be able to solve my issues. I’ve applied for the beta. Would you mind putting in a good word for me?

Can you provide a link to one of these failing builds? Also note that the supported python versions are listed in the repo for the build image: build-image/included_software.md at xenial · netlify/build-image · GitHub As of this writing, that’s 2.7, 3.5, and 3.7. If you try and specify a different version from those three, it will fail.

Sure, here’s one build Netlify App.

You’ve correctly identified that it is because 3.8 is not present. We’re on 3.8 for our code. The docs don’t strictly need it, so I’d be fine with using a lower version to build the docs, but it automatically attempts to install dependencies from the Pipfile. If I could manually specify the build step, I could avoid that scenario.

That said, the image should have 3.8 installed as well, ideally. But if you’re focusing efforts on the new build approach, which seems perfectly logical to me, and therefore you don’t want to spend to much effort on the current image, then perhaps you can put in a good word for me so that I can get in on the beta of the new build approach?

Absolutely can and did put that word in for you, Ryan! I think you’ll hear back soon if you haven’t already :wink: