consider doxidize support

[gnzlbg]

doxidize comes with a publish subcommand: https://steveklabnik.github.io/doxidize/users-guide/publish.html

It might be worth it to start thinking about how to integrate that in cargo-travis. It could detect the Doxidize.toml file, and if so, use doxidize publish to publish the documentation instead of using cargo doc, maybe.

It is unclear to me how API documentation for different targets can be generated using this approach.

[CAD97]

See also https://github.com/crate-ci/cargo-ghp-upload where I've extracted the doc upload portion of logic to its own crate. I'm still not exactly certain where cargo-travis stands in crate-ci's plans but it'd be nice to at least link this discussion over there.

The primary advantage of using the ghp-upload functionality that I've iterated from the original travis-cargo script is the fact that it respects git history.

Ghp-upload only does one thing, which is to upload ./target/docs to [user].github.io/[repo]/[branch]. While it does clean out that directory (I'll probably be adding a toggle to turn that off), it very deliberately leaves other directories alone and does not modify the root index.html.

I don't actually have a project that has target-specific documentation to try it out on, but (barring unifying docs and displaying target specific information), you can create a subdirectory structure in the folder that you're using, and then upload that.

This was typed on my phone with very little preview space so forgive the formatting. This has made me realize a group of specific actionable improvements to ghp-upload so expect a couple of related issues to spawn over there.

[roblabla]

Regarding crate-ci, I haven't had enough time to work on it. One of the things I'd like to do is start a "cargo-metadata" crate that allows interacting with cargo in a simple, foolproof way, sort of mimicking the current (unstable) cargo API, but by invoking the subcommand and parsing the JSON output. This would give us a robust API on top of which I could reimplement cargo-travis, and include it in crate-ci.

I'm also considering removing the documentation support and asking people to use cargo-ghp-upload instead, but that will break people's build 😢 . I wonder if it'd be possible to somehow "depend" on cargo-ghp-upload and redirect the docs subcommand to it? I'm kind of afraid we're going to end up duplicating work if we continue in this direction.

[CAD97]

cargo-ghp-upload's current interface is backwards compatible with this repo's cargo-doc-upload. It should be fairly simple to write a wrapper that takes cargo doc-upload ... and turns it into cargo ghp-upload (and prints a deprecation warning).