Fix docs publishing when java-sdk is in the packages list#69434
Merged
Conversation
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.
…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.
uranusjr
reviewed
Jul 6, 2026
uranusjr
reviewed
Jul 6, 2026
uranusjr
reviewed
Jul 6, 2026
uranusjr
reviewed
Jul 6, 2026
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).
phanikumv
reviewed
Jul 6, 2026
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
approved these changes
Jul 7, 2026
Contributor
Backport failed to create: v3-3-test. View the failure log Run detailsNote: As of Merging PRs targeted for Airflow 3.X In matter of doubt please ask in #release-management Slack channel.
You can attempt to backport this manually by running: cherry_picker f193bbd v3-3-testThis should apply the commit to the v3-3-test branch and leave the commit in conflict state marking After you have resolved the conflicts, you can continue the backport process by running: cherry_picker --continueIf you don't have cherry-picker installed, see the installation guide. |
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.
Why
Publishing the Java SDK docs never worked end to end:
include-docscontainingjava-sdkfails the Sphinx build job (the Java SDK docs are a Dokka build, not a Sphinx package), andbreeze release-management publish-docscannot resolve thejava-sdkpackage name, so even aninclude-docs: allpublish from a ref containingjava-sdk/would crash at the publish step.What
java-sdkout of the packages passed tobreeze build-docs, skip the Sphinx build entirely for a java-sdk-only run (an empty list would mean "build everything"), and drop the redundantJAVA_SDK_DOCSpublish argument.java-sdktoREGULAR_DOC_PACKAGESsopublish-docsresolves it, and skip packages whose docs were not staged instead of failing on version resolution, so publishes from refs withoutjava-sdk/keep working unchanged.java-sdkdocs version fromjava-sdk/gradle.propertieswhen staged docs lackstable.txt, mirroring the source-fallback the other doc packages have (get_java_sdk_versionmoved toglobal_constants).java-sdkpackage resolution, the publish skip ordering, and version resolution.Was generative AI tooling used to co-author this PR?