Skip to content

docs: publish versioned docs from versions.json with a workflow and build script - #26828

Draft
alamb wants to merge 2 commits into
apache:mainfrom
alamb:docs/versioned-docs-rebuild
Draft

alamb wants to merge 2 commits into
apache:mainfrom
alamb:docs/versioned-docs-rebuild

Conversation

@alamb

@alamb alamb commented Oct 27, 2026 •

Copy link
Copy Markdown
Contributor

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?

  • Add a script to rebuild the older version docs
  • Add a work that triggers to run on older versions

Are these changes tested?

Yes, I tested end to end on my fork, preview at https://alamb.github.io/datafusion/

The 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

We are going to make a draft PR to implement this: #24792 (comment)
The end user visible goal is to reduce the manual work required for release
I want a new github action that will rebuild released docs versions so they pick up any changes to the theme and so we have a way to backfill old versions
The action should be triggered on changes to docs/source/_static/versions.json

I want to test this using my fork of datafusion. First setup my fork with a mirror of what the apache fork does on commit: rebuild the docs. But instead of letting the asf publishing mechanism work, instead configure github pages to serve the new documentation

I want the jobs to be as close as possible to the current jobs on the apache fork so we can test proposed changes to the apache fork easily there.

Also disable CI on PRs to the main branch of my fork. No reason to waste CI time.

This way if I made a PR to my fork that changes something about the docs, it should redeploy to github pages

Please setup my fork this way. We'll make sure it works, and then we'll make the draft PR to auto rebuild old versions on changes to versions

…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>
@github-actions github-actions Bot added documentation Improvements or additions to documentation development-process Related to development process of DataFusion labels Oct 27, 2026
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>
# specific language governing permissions and limitations
# under the License.

name: Prepare Docs Builder

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

refactored common builder setup

contents: write
name: Build docs
runs-on: ubuntu-latest
runs-on: ubuntu-slim

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

calls the new script, and then the lines below copy this to the right place on asf-site

Comment thread dev/release/README.md
**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

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is the script that automates building old releases

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

development-process Related to development process of DataFusion documentation Improvements or additions to documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant