Custom draft URLs for manual deploys

We are deploying our static Netlify sites manually using netlify deploy (since our sites are built as part of a bigger build pipeline outside of Netlify), and we need to know the absolute URL of each deploy in our backend, so that we can correctly test things like e-mail verification flows (for which we need the correct link in the emails) in our draft deploys before publishing them.

However, because we don’t have access to the DEPLOY_URL environment variable outside of the Netlify build environment, we are unable to make this happen. Since we are already deploying manually, would it be possible to pass a custom draft URL or deploy ID to netlify deploy?

Hiya @sanderp!

When you deploy via CLI, you should receive a link to your deployment in the format https://DEPLOY_ID_HASH–sitename.netlify.com in the output. Is this not happening for you? then you would of course have to save it and use it, but we do intend to tell you immediately upon commit (for draft deploys only, of course - production deploys use the production URL).

If you got that information reliably, would your feature request still stand? I don’t think we’ll be likely to implement it since there is a 1:1 mapping between deploy ID and our system that is already created/fully functional so we’d have to have a better use case to file a feature request than just “I prefer not to use the netlify ID” :slight_smile:

So - thanks in advance for talking through it with me so I can either help you find a different solution, or get a decent feature request filed!

Hey, thanks for getting back to me.

Yeah, the CLI deploy prints the deployment link allright, but we since we are building the site in our own pipeline and not on Netlify, we need the link at build-time, not deploy time.

Ideally, we would be able to deploy using something like

netlify deploy --id $GIT_COMMIT_SHA

So that Netlify uses that as the deploy ID, and the draft URL would become https://GIT_COMMIT_SHA--sitename.netlify.com.

This would give us the ability to configure the unique deploy URL in our system while building it.

Correct me if I’m wrong, but that feature wouldn’t have a large impact on the current system, right? It would just take over the generation of the deploy ID, the rest should work exactly as before.

Yes, I understand what you want :slight_smile: As I explained, it is not likely to happen, since unfortunately from our side it IS a major change to the existing system (which thousands of people have already automated using the existing patterns). So, let’s come up with a different plan that can work for you!

I still don’t understand why you need the link at deploy time. The best practice is to use relative URL’s, so /asset.png rather than https://deployid--sitename.netlify.com/asset.png, which would mean that the site works at any hostname. Could that work for you?

If not, things get hairier but still possible: you could create your own API client against our API (see [Common Issue] Understanding and using Netlify's API for details) to manage things using a workflow like this:

  1. you’d do a build using placeholders for the URL,
  2. you’d post to our post to our “create deploy” endpoint, which returns the deploy ID,
  3. …and be able to modify your files to use it…
  4. before uploading them.

That’s not something we can give a lot of tech support on, so I’d encourage you to keep looking for a way NOT to need that URL which I look at as antipattern - it’s only really useful/intended for sharing or testing after deploying and shouldn’t be referenced internally within the deploy, in my experience.

Again, thanks for getting back to me and thinking along, it’s much appreciated! You might be right, maybe there is a better way to tackle my issue.

Let me explain the situation in more detail, which hopefully gives you enough context about what I’m trying to do.

Context

We own a set of Netlify sites that together form the website of a brand. Each Netlify site contains a Gatsby site for a single country, so that we can update content per country individually (otherwise build times would go through the roof).

Next to the country-specific sites, we have one Netlify site that is connected to the brand domain (let’s say www.brandname.com). This Netlify site proxies requests from /[country-code]/* to their respective country-specific sites using a _redirects file.

Current situation

  1. A user visits https://www.brandname.com/us/*
  2. The request is proxied to https://brandname-us.netlify.com/us/:splat
  3. The statically built page loads assets from /us/asset.js, which have to go through the proxy as well

Preferred situation

  1. A user visits https://www.brandname.com/us/*
  2. The request is proxied to https://brandname-us.netlify.com/us/:splat
  3. The statically built page loads assets from https://brandname-us.netlify.com/asset.js (or https://[deploy-id]--brandname-us.netlify.com/asset.js when it’s a draft deploy)

Having the assets and Netlify Functions available under the /[country-code] prefix has a lot of downsides:

  1. The build process is very complicated
    • We have to move around assets after building them to get them served from the correct path
    • We have to fix references to those assets in the generated HTML
    • We have to fix references from assets to their source maps to get front-end monitoring working
  2. All assets and function calls go through one or more proxies, which has (a small, but still relevant) impact on the response time
  3. We’re not even sure if this whole mechanism works with in combination with the CDN/caching features of Netlify

Regarding the differences in the 3rd step:

  1. The statically built page loads assets from https://brandname-us.netlify.com/asset.js (or https://[deploy-id]--brandname-us.netlify.com/asset.js when it’s a draft deploy)

The only way I can see to do that would be for the site HTML to itself reference these domains directly. Instead of path-only reference like:

<script src="/asset.js"></script>

The HTML would reference the full URL including the domain like so:

<script src="https://brandname-us.netlify.com/asset.js"></script>

Because you would know where the files were deployed, they could contain the domain name of the site and avoid proxying this way. CORS headers may be required to support this configuration though.

Regarding including the deploy id in domain name of these asset references, this is currently only possible using Netlify for the build or the workaround that @fool describes above.