search

jimporter / mike

Manage multiple versions of your MkDocs-powered documentation via Git
BSD 3-Clause "New" or "Revised" License
511 stars 45 forks source link

Deploy without build #155

Closed samuelcolvin closed 1 year ago

samuelcolvin commented 1 year ago

I would like to use mike to deploy from a site that has already been build (in CI) - would be great if this was available as a separate command or argument to mike deploy.

jimporter commented 1 year ago

Sorry, but this isn't really possible (at least not without a lot of extra work). mike deploy doesn't just call mkdocs build; it inserts itself into the MkDocs build process and overrides some of the settings in your mkdocs.yml configuration based on the command-line arguments to mike deploy.

samuelcolvin commented 1 year ago

What about a mike build command that does build but leaves the new files in a directory in the current branch?

jimporter commented 1 year ago

That wouldn't work either, since it would also need special handling for the versions.json file in the root directory.

In practice, I think the way to do what you want would simply be to save the diff created by mike deploy (e.g. with git format-patch) and then apply it and push upstream when you want (e.g. with git am).

samuelcolvin commented 1 year ago

makes sense, thanks so much.

jimporter commented 1 year ago

Oh, I guess I should add: in general, one of the benefits (I hope) of mike is that every change is just a Git commit. That means that you can use any of the various Git subcommands to work with the mike-generated commits. So for example, my above suggestion is pretty close to the email-based Git workflow, where the author of a change sends a patch file to a mailing list via git format-patch or git send-email, and then the maintainer applies the patch via git am.