-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upload pre-built docs #1083
Comments
We agree this would be an awesome feature, we've already talked about how this might work and it's vaguely on our roadmap already. |
what is the status of APIv2.1? |
👍 to this. I could really use a "dumb file upload" API, where I can just provide a zip/tar/whatever of HTML+CSS files, along with some basic metadata like what version it's for. |
I'm also very interested in this. Since I try to generate as much documentation via the code comments it would be very easy to, during CI, generate the pages, and upload to RTD - without the need for checking-in these generated files! |
IIRC this used to work, or at least, there was a file upload option but it was removed? What needs to be done to overcome the original problems with this feature? It would be nice to have again, and could even allow us to offload some build overhead from RTD. |
Maybe it has been removed, so people don't misuse rtfd as a free hosting service? |
I believe it was once a feature of RTD, but it was removed. We'd like to have this supported with an overhaul of the API -- a task we haven't added to our roadmap yet. The more pressing issue we need to take a stance on is what are we accepting via html upload. RTD doesn't aim to be just a file host -- you could output and host documentation almost anywhere on the internet. Our goal is making the documentation authoring and viewing experience great, with Sphinx being our primary focus. The documentation experience would go south if we just took any old html and hosted it. We don't have the resources or community support to improve the experience of al the various documentation output folks use. We're still shaping our opinion here, but we look to support some form of integration with externally built sphinx documentation, via some local command wrappers that you could run on external CI services/etc. We don't have an ETA on when we might drop that on our roadmap yet, but it is on our radar. |
It seems the biggest issue is then just ensuring a certain level of quality, and now allowing spam and or non-docs to be hosted. Perhaps the feature could be enabled only for validated users. Or maybe even paying (?) users? I can see how it would be difficult to handle that resource-wise though. |
… to commit this to repo until readthedocs/readthedocs.org#1083 is done
This feature would be great, even it was turned off on the public RTD server, but available for corporate-hosted ones in which the concerns over hosting generic HTML would not be an issue. The builds of our repos are just to contorted to expect a RTD server to check out and build, whereas our Jenkins CI server does all of that already. |
I can't get RTD to compile my project because of external dependencies that require OS modules. I'd love to be able to upload my compiled docs. Since this issue isn't moving I have to rely on pythonhosted and kill the RTD entry for my project, loosing some SEO love.... |
@mistercrunch if you don't use these dependencies within your documentation at all, you can mock them out or use conda. |
I would love to see this too. We are having hard time mocking our deps in RTD and we already build on Travis. Conda may help here, but still it seems like duplicating efforts given that we already have everything in Travis... Alternatively, if we could run in RTD the same docker containers that we already use in Travis, that would also be great. |
Hi all! This topic was raised again and we started discussing about it and having a brainstorming of ideas. Although, we don't have a clear direction on what to support and/or how and/or where (community/corporate site). We have some things to consider for anything that we implement:
On the other hand, we need to consider other things around the workflow,
Please, if you have some ideas to share about this topic, write them down here to help us to take the right direction on this. We still don't know where this feature fits better, though. |
The docker option also sounds very interesting as it would make mocking c-extensions completely obsolete. |
My project requires building the docs from a C++ library that requires GCC-10 or llvm+libc++ to build, so it cant be built on the RTD docker images. this would be nice to see |
What about allowing certain docker images for building (on RTD of course), validating the build output outside of that and then, if a "stack"-reviewer accepts it, release it into the wild wild internet. |
👋 So, just an update here for anyone following along: This is loosely going on our roadmap for sometime this year. However, we have a number of technical pieces we need to handle first. There are some big question marks here still. That said, a number of the issues in comments here already have solutions available, without requiring upload of pre-built documentation. In the better part of a decade this issue has been open, we've addressed a number of build and dependency issues with new features: My project requires special OS packagesYou can use My project needs to execute special commands before buildWe'll have a beta in the next couple weeks for My project executes different commands than Read the DocsWe are gathering feedback for this feature. Perhaps If you have other use cases that are not well covered by our build infrastructure now, feel free to open a separate issue. I'll keep this issue open, but we'll be putting discrete issues on our roadmap. I'll remove the design decision designation, not to communicate we have a concrete plan here, but we'll have discussion on individual issues as they come up. There are certainly a lot of questions here still. |
We haven't had any serious progress here yet this year, but I am currently experimenting with a solution for this using Noting for later, my proof of concept is at: I wouldn't recommend this for use yet, there are a few things that will likely change here. I think a one-time codeword would be a good addition and wormhole relays seem unstable. A drop in replacement would be croc or maybe even running a private relay |
I'm also very interested in this feature. Our build processes are quite complex and involve a substantial amount of work to complete. Documentation is extracted partly from the compiled code (notably Python extension modules built using C++ and Boost.Python), so running those build processes within RTD is not really an option. |
Have you tested the solution proposed by @agjohnson in #1083 (comment). We would appreciate your feedback on that. |
Hi, I'm interested in this as well, but from a slightly different Standpoint. We are using OctopusDeploy to release our python modules to multiple environments. I don't want to release the Documentation until the code hits a specific environment. So I want to build the docs once, then deploy them to each environment as the release proceeds though out testing process. Also, we have a complicated build pipeline with a bunch of C++ dependencies and CMake etc. So I would really just like a HTTP REST API to upload a documentation package ideally... Just putting this here to add a little different perspective. GitHub branches in this case aren't our ideal workflow. I could probably get around it with tagging... But not ideal. And then there is the whole build steps... |
Just FYI, I have found https://github.com/Polyconseil/dokang which provides a simple documentation hub to which one can push any documentation html tree. This works reasonably well for me, but isn't actually maintained (and much less developed), so I would very much welcome any effort to offer this reduced feature set as part of the |
Is there any update on this topic? |
Unfortunately, not too many relevant updates here. However, we are going to discuss about this topic again in the near future and figure it out if there is a potential way to integrate this idea into Read the Docs without breaking the versions pattern we use. |
Next steps here are to scope this work. There's some discussion ongoing here: https://github.com/readthedocs/meta/discussions/147#discussioncomment-11308657 |
Thanks for the update! Unfortunately, your link doesn't work. |
Yea, that's on an internal repo for now, we've had a number of conversations about this in various contexts over the years 🙃 . The plan is to take the discussion there and write up a minimal v1 of the product that we'll work on here. |
I'm moving this issue out from our roadmap since we already discussed it and we are not thinking about implementing HTML upload for now. We will start allowing users to update the
That feature is not exactly HTML upload but it will solves that use case as well. Users can build their docs outside Read the Docs and point a version to a specific branch that executes build:
commands:
- wget https://your-organization.com/assets/docs.html.zip
- unzip docs.zip --output=$READTHEDOCS_OUTPUT/html This idea can be combined with a GitHub Action (or similar) that builds your docs and triggers a build for this version on Read the Docs using the APIv3. |
I wonder if that would be possible? Would be extremely useful, since I'm building and deploying my packages with travis, and could perform the doc building also during this runs.
You may ask why this is necessary, since its not obvious that I can not use your build environment for documentation. I've to convert some ipython notebooks with cabal to rst and include them in my sphinx build. This aint possible on RTD and probably will never be.
Thanks for your effort!
Front conversations
The text was updated successfully, but these errors were encountered: