What am I proposing?

Currently Hugo has renderSegments. I'd like to propose similar functionality for deploy, a --deploySegments flag on the hugo deploy command.

Why?

Mostly for smarter informed deploy, typically there might be some logic or trigger for a build. Maybe in a normal scenario you might render segment1,segment2 and you could just hugo deploy that as it only exists in the public dir. You would have to do some careful includes,excludes or maxdeletes 0 to make sure its not removing non segments in the remote... but with a deploy segments command you would just run the deploy command with the same segments for deploy

How might it work?

Ideally it would mirror the functionality. For example you could run something like below and it would understand the segment concept from the config and which of the built files in ./public are appropriate to deploy.

hugo deploy --deploySegments segment1

A few things come to mind though:

One of the issues with this is at deploy time it has no concept of the relationship between the segment (source md) files and the output (built html) files. It only has the built files to deal with.

Some thoughts on that:

• Try and infer the relationship based on path or other telltale signs although its probably error prone
• Generate a “segment outputs” manifest during the build or a separate command in hugo. This would output a mapping of segment -> built files in a json file in the public folder that could be read during deploy time. The deploy function would treat this almost as if these are the only files in the public folder so you could still do include/exclude logic etc on top if desired.

Alternatives

• Manually use includes/excludes on the deploy config to map your understanding of the built files that map to what you want?
• Other deploy tools?