allow subdirectory deploys to deploy a portion of a site rather than overwriting.

[nolessafool]

If you generate your site in pieces, it would be great to be able to deploy just a portion of the site. The API supports this in some sense, so this could just be a wrapper that fetches last-deploy info and grafts all the unchanging paths into a deploy with the changed path(s).

[rybit]

So we do diffing of the files uploaded. If you regenerate and only change a part ~ the cli will only upload those files that have changed. We send the list of all the files in the deploy to the API and the API responds with what files it needs. Files are globally de-dupped, so you won't need to upload common files (e.g. jquery). It also means that if you didn't change part of your site, it won't be reuploaded.

[nolessafool]

I'm well aware but that does not affect this feature request. What if you
only have a piece of the site, or one file and want to deploy it from the
cli¿

On Nov 16, 2016 12:25, "Ryan Neal" notifications@github.com wrote:

So we do diffing of the files uploaded. If you regenerate and only change
a part ~ the cli will only upload those files that have changed. We send
the list of all the files in the deploy to the API and the API responds
with what files it needs. Files are globally de-dupped, so you won't need
to upload common files (e.g. jquery). It also means that if you didn't
change part of your site, it won't be reuploaded.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#16 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAN-oM2CROWp9WK8QEGALAFKXaFWHmjcks5q-zyOgaJpZM4Kz9cU
.

[bcomnes]

Our API only supports entire deploys. Like @rybit said, we de-dupde and only process the files that changed, but any files not included in that deploy process are considered to not exist. We can't copy part of a previous deploy into a new deploy with a subtree of that new deploy updated at the API level.

This remains a userspace/build time problem. Either take advantage of partial regeneration in your site generator or play around with the build cache in the build bots with a ssg that supports partial regeneration.

If there is demand for this feature, we'll have to bring it up with platform. The CLI is simply a client to the API.

[minchinweb]

@bcomnes I'm moving from GitHub pages, and they have a feature that allows you to set up your "main" site, and then any project pages you publish (without changing the setting elsewhere) are available as a sub-folder of your main site.

For example, my main site is here --> http://minchin.ca/ and the repo is here --> https://github.com/MinchinWeb/minchinweb.github.io
An example project is here --> http://minchin.ca/openttd-progressive-rail/ and the repo is here --> https://github.com/MinchinWeb/openttd-progressive-rail/tree/gh-pages

In theory, I could move my projects to sub-domains, or a git submodule of my main site, but the effort has kept me from moving my site from GitHub pages to Netlify. If the feature was available, that's how I'd use it.

[bcomnes]

I used gh pages extensively before Netlify and definitely agree, their repo namespace -> gh-pages path deploys are a cool feature. They aren't without their issues (e.g. what happens if your name.github.io starts publishing files in the same namespace as sub-path gh-pages site does?) due to opaque override rules and shared name spaces. Its my understanding netlify isn't going to support this anytime soon beyond what we already support with our comprehensive redirect tooling (https://www.netlify.com/docs/redirects/)

One way I adapted around this feature when moving to netlify was to experiment with multi-repo sites. E.g. define a primary site repo, and set up a build process that clones in every other repo (or use submodules like you said) and dependencies needed for the complete site build and set up webhooks from every repo involved to trigger site builds.

[nolessafool]

You can already achieve this functionality with a bit more work. High level workflow:

• set up second repo on separate netlify site. Deploy it under /openttd-progressive-rail (so instead of /index.html, you have /openttd-progressive-rail/index.html)
• on the main site (which has /index.html for your main site, e.g. http://minchin.ca/) use the proxying feature to proxy to the other site:
  /openttd-progressive-rail/* https://othersite.netlify.com/openttd-progressive-rail/:splat 200!
• ???
• profit :)

It's not as easy as GH makes it, but it is possible and used in production by many customers. Our helpdesk can provide a more detailed example if you're confused, or help debugging if it doesn't seem to be working as it should when you try it.

[bcomnes]

Thanks @fool that looks like a decent solution as well!