Repository navigation
Auto-rebuild docs when a mounted local sphinx_airflow_theme changes - #75743
sreecharan-desu wants to merge 3 commits into
Conversation
|
@potiuk hey, this one's stuck on workflow approval (breeze build-docs bits) |
|
hey @potiuk quick heads up on the red checks this one only changes breeze / sphinx docs watch stuff the prod dockerfile example fail is an apt / bzip2 dep conflict i cant re-run from the fork |
61abdf4 to
846282a
Compare
|
Your CI change needs a maintainer. CI for this pull request runs in your fork, and the workflow runs it starts in apache/airflow are approved automatically while they only run the fork CI gate. This pull request changes files that define what CI runs:
Such a change can make project CI run on the project's runners, so its workflow runs in apache/airflow wait for a maintainer to review the change and approve them. CI in your fork is not affected, and its result stays visible on this pull request. Pull requests from contributors run their CI in the contributor's own fork. GitHub Actions is free and has no minute limit on public forks, while the CI capacity of the Apache Software Foundation is shared by every ASF project and is finite. This comment was posted automatically by the fork CI monitor from templates drafted with an AI-assisted tool, so it may contain mistakes. An Apache Airflow maintainer, a real person, will review the pull request once its fork CI is green. Why the first pass is automated. |
|
Fork CI: green, needs a maintainer. CI for the latest commit passed in your fork, but this pull request changes files that decide which CI jobs run and where ( Pull requests from contributors run their CI in the contributor's own fork. GitHub Actions is free and has no minute limit on public forks, while the CI capacity of the Apache Software Foundation is shared by every ASF project and is finite. Latest run: https://github.com/sreecharan-desu/airflow/actions/runs/41562450095 How this works: fork CI for external contributors. This comment was posted automatically by the fork CI monitor from templates drafted with an AI-assisted tool, so it may contain mistakes. An Apache Airflow maintainer, a real person, will review the pull request once its fork CI is green. Why the first pass is automated. |
846282a to
db7f41c
Compare
When building docs with a local sphinx_airflow_theme mounted at /opt/sphinx_airflow_theme: - install the mounted theme in editable mode in run_docs_build.sh so template and static asset edits take effect without reinstalling; - pass --watch /opt/sphinx_airflow_theme/sphinx_airflow_theme to sphinx-autobuild when --autobuild is enabled and the theme mount is present; and - expose --autobuild on breeze build-docs and forward it to docs_build/build_docs.py. Closes: apache#75374
e78d8de to
a552d02
Compare
closes: #75374
Following up on #75001 and @potiuk's suggestion on #70139 (cc @shahar1), when
/opt/sphinx_airflow_themeis mounted into the Breeze container we now install it with--editableinrun_docs_build.shso local template and static asset changes take effect without reinstalling.When
--autobuildis enabled (breeze build-docs --autobuild),AirflowDocsBuilderalso passes--watch /opt/sphinx_airflow_theme/sphinx_airflow_themetosphinx-autobuildwhenever the mounted theme directory is present.Tested locally:
uv run --project dev/breeze pytest dev/breeze/tests/test_developer_commands.py -xvs && uv run --project devel-common pytest devel-common/tests/unit/sphinx_exts/docs_build/test_docs_builder.py -xvsWas generative AI tooling used to co-author this PR?
Generated-by: an AI coding assistant, reviewed and tested by me, following the guidelines
used an AI coding assistant to help with parts of this, but i went through every change myself, understand the code and tested it locally.