Repository navigation
Conversation
…uild script Add docs/scripts/build_versions.sh, which builds the documentation for the releases listed in docs/source/_static/versions.json from their git tags using the release configuration overlay, and a workflow that runs it when the manifest (or the overlay, script, or Python dependencies) changes on main and mirrors the result into versions/ on asf-site. Update the release instructions accordingly: a release is published by adding it to versions.json. Also: - factor the docs builder setup shared by docs.yaml, docs_pr.yaml and the new workflow into .github/actions/setup-docs-builder and run the docs jobs on ubuntu-slim - share a concurrency group between the two workflows that push to asf-site - make the site base path configurable (DATAFUSION_DOCS_BASE_PATH) so a fork can test the site, including the version picker, on GitHub Pages Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The apache site is served at the root, so the version picker's absolute paths work as-is. The base path override only mattered for testing on a fork's GitHub Pages sub-path. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
alamb
commented
Oct 27, 2026
| # specific language governing permissions and limitations | ||
| # under the License. | ||
|
|
||
| name: Prepare Docs Builder |
Contributor
Author
There was a problem hiding this comment.
refactored common builder setup
| contents: write | ||
| name: Build docs | ||
| runs-on: ubuntu-latest | ||
| runs-on: ubuntu-slim |
Contributor
Author
There was a problem hiding this comment.
We can run this on unbuntu-slim to save CI credits as everything is single threaded (though we do have to intall rust, so it takes a bit longer)
| DATAFUSION_DOCS_BASE_PATH: ${{ vars.DATAFUSION_DOCS_BASE_PATH }} | ||
| run: | | ||
| set -x | ||
| docs/scripts/build_versions.sh --output docs/build/versions |
Contributor
Author
There was a problem hiding this comment.
calls the new script, and then the lines below copy this to the right place on asf-site
| **1. Build the documentation from the release tag** using the configuration | ||
| overlay (`docs/scripts/release/conf.py`) from the main checkout. For example, | ||
| for `55.0.0`, from the repository root: | ||
| Open a PR against `main` that adds the release to |
Contributor
Author
There was a problem hiding this comment.
I think this is the best demonstration of what I am trying to accomplish with this PR. The instructions are quite simple
| @@ -0,0 +1,200 @@ | |||
| #!/usr/bin/env bash | |||
Contributor
Author
There was a problem hiding this comment.
this is the script that automates building old releases
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Which issue does this PR close?
Rationale for this change
I want to reduce the manual work required for release, and make it easy to re-create documentation for different versions.
The instructions added in #17071 are pretty complicated and will make doing releases harder and it is also non trivial to recreate documentation for older releases.
What changes are included in this PR?
Are these changes tested?
Yes, I tested end to end on my fork, preview at https://alamb.github.io/datafusion/
versions.jsonThe workflow then ran and build the docs for the new versions here:
https://github.com/alamb/datafusion/actions/runs/40573488991/job/122436486860
Once we merge this then we can just merge this PR and build old releases
Are there any user-facing changes?
No changes to the published site contents. Release managers publish versioned docs with a single PR to
main.Original request