Skip to content

Fix docs publishing when java-sdk is in the packages list#69434

Merged
potiuk merged 4 commits into
apache:mainfrom
jason810496:ci/fix-java-sdk-docs-publishing
Jul 7, 2026
Merged

Fix docs publishing when java-sdk is in the packages list#69434
potiuk merged 4 commits into
apache:mainfrom
jason810496:ci/fix-java-sdk-docs-publishing

Conversation

@jason810496

@jason810496 jason810496 commented Jul 6, 2026

Copy link
Copy Markdown
Member

Why

Publishing the Java SDK docs never worked end to end: include-docs containing java-sdk fails the Sphinx build job (the Java SDK docs are a Dokka build, not a Sphinx package), and breeze release-management publish-docs cannot resolve the java-sdk package name, so even an include-docs: all publish from a ref containing java-sdk/ would crash at the publish step.

What

  • Workflow: filter java-sdk out of the packages passed to breeze build-docs, skip the Sphinx build entirely for a java-sdk-only run (an empty list would mean "build everything"), and drop the redundant JAVA_SDK_DOCS publish argument.
  • Breeze: add java-sdk to REGULAR_DOC_PACKAGES so publish-docs resolves it, and skip packages whose docs were not staged instead of failing on version resolution, so publishes from refs without java-sdk/ keep working unchanged.
  • Breeze: resolve the java-sdk docs version from java-sdk/gradle.properties when staged docs lack stable.txt, mirroring the source-fallback the other doc packages have (get_java_sdk_version moved to global_constants).
  • Regenerate breeze help images and add tests for java-sdk package resolution, the publish skip ordering, and version resolution.

Was generative AI tooling used to co-author this PR?

Publishing the Java SDK docs never worked end to end: passing java-sdk in
include-docs failed the Sphinx build job (java-sdk is a Dokka build, not a
Sphinx package), and breeze release-management publish-docs could not
resolve the java-sdk package name at all, so even full 'all' publishes from
a ref containing java-sdk/ would have crashed at the publish step. Filter
java-sdk out of the Sphinx build (skipping it entirely for a java-sdk-only
run), teach breeze the java-sdk doc package, and skip packages whose docs
were not staged instead of failing on version resolution, so publishes from
refs without java-sdk keep working unchanged.
@jason810496 jason810496 self-assigned this Jul 6, 2026
…is missing

Review follow-up: a staged-but-incomplete java-sdk docs dir (stable/ present,
stable.txt missing) crashed publish-docs with "Unsupported package"; fall back
to the version in java-sdk/gradle.properties like the other doc packages fall
back to their sources. Also cover the publish skip-ordering and the stable.txt
version resolution with tests.
Comment thread dev/breeze/src/airflow_breeze/utils/docs_publisher.py Outdated
Comment thread dev/breeze/src/airflow_breeze/commands/release_management_commands.py Outdated
Comment thread .github/workflows/publish-docs-to-s3.yml Outdated
Comment thread .github/workflows/publish-docs-to-s3.yml Outdated
Review follow-up: the workflow echo messages already describe the skip
behaviour, the java-sdk None-return folds into the adjacent check, and the
skip-before-version-resolution comment claimed a stale SystemExit reason
instead of the real one (no version resolution and no output-dir deletion
for packages with nothing staged).
Comment thread dev/breeze/tests/test_docs_publisher.py
Review follow-up: pin the destructive pre-reorder behaviour where an
override-versioned publish deleted an already-published directory and then
skipped because the build dir was missing.
@potiuk potiuk merged commit f193bbd into apache:main Jul 7, 2026
148 checks passed
@github-actions

github-actions Bot commented Jul 7, 2026

Copy link
Copy Markdown
Contributor

Backport failed to create: v3-3-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status Branch Result
v3-3-test Commit Link

You can attempt to backport this manually by running:

cherry_picker f193bbd v3-3-test

This should apply the commit to the v3-3-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

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

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants