Catch KDoc/Javadoc links to buildSrc and run Dokka in pre-pr#13
Conversation
The `tool-base` publish build failed in `dokkaGeneratePublicationHtml` because a KDoc comment linked `[io.spine.gradle.report.coverage.KoverConfig]`, a type that lives only in `buildSrc`. `buildSrc` is a separate compilation unit Dokka cannot see, so the link never resolved; Dokka fails on warnings, so the publish job broke while `./gradlew build` still passed. The existing API-doc-scope rule only forbade textual mentions of `buildSrc/`, not symbol links whose package (e.g. `io.spine.gradle.*`) carries no `buildSrc` substring. And nothing ran Dokka before CI: `pre-pr` runs `./gradlew build`, which does not invoke Dokka, and the docs-only path used the bare `dokka` task, which is ambiguous under Dokka v2 and aborts. - guidelines/documentation.md: forbid KDoc/Javadoc links to buildSrc/config types, with the failure mechanism and a code-span fix. - review-docs: add the matching Must-fix reviewer check. - pre-pr: append `dokkaGenerate` whenever code or docs changed; skip gracefully when Dokka is not applied; a Dokka failure is a Must-fix. - running-builds.md, writer: replace the broken `./gradlew dokka` with `dokkaGenerate`. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
This PR tightens documentation guidance and pre-PR checks to prevent Dokka failures caused by unresolved KDoc/Javadoc symbol links to types that live in buildSrc (a separate compilation unit not visible to Dokka when generating published docs), and standardizes on ./gradlew dokkaGenerate (vs the ambiguous dokka task).
Changes:
- Update build-running guidance to prefer
./gradlew dokkaGenerate, and to run Dokka alongsidebuildwhen code/docs changes could break existing doc links. - Extend documentation/review guidelines to explicitly forbid symbol links (KDoc/Javadoc) to
buildSrc/config-only types and explain the remediation. - Update reviewer/pre-PR skills to enforce/encourage the above and treat Dokka failures as Must-fix.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| skills/writer/SKILL.md | Updates validation guidance for doc-only Kotlin/Java changes to prefer ./gradlew dokkaGenerate. |
| skills/review-docs/SKILL.md | Adds a Must-fix rule forbidding symbol links to buildSrc/config-only types; updates Dokka command guidance. |
| skills/pre-pr/SKILL.md | Updates docs-only build target to dokkaGenerate and instructs appending Dokka generation when code/docs change. |
| guidelines/running-builds.md | Replaces ./gradlew dokka with ./gradlew dokkaGenerate and explains why; adds guidance to run Dokka when KDoc/Javadoc could be impacted. |
| guidelines/documentation.md | Adds a section explicitly forbidding doc links to buildSrc/config types and provides a recommended rewrite pattern. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 617014005d
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…c-links # Conflicts: # skills/pre-pr/SKILL.md
- pre-pr: gate the extra `dokkaGenerate` on `.kt`/`.java` source or doc changes, not the broader `code` class — a pure `*.kts`/build-script edit no longer forces a Dokka run (Codex P2). - documentation.md: make the example a valid KDoc comment (`/** … */`) and stop naming `buildSrc` inside the "right" API-doc sample, consistent with the no-internal-references rule (Copilot + Codex P2). - review-docs: scope the Must-fix to doc comments in published sources; a doc comment under `buildSrc/` linking a sibling `buildSrc` type compiles in the same unit and resolves fine, so it is not flagged (Codex P2). Fix the broken inline code span around the section reference (Copilot). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- running-builds.md: qualify the "runs HTML and Javadoc" claim — it holds because the Spine config applies both the HTML and Javadoc Dokka plugins; a base-plugin-only project gets HTML alone (Copilot). - claude/commands/run-build.md: replace the broken `./gradlew dokka` with `dokkaGenerate` and mirror the run-Dokka-on-source-change guidance, so the command no longer contradicts the guideline (Copilot). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
@codex, review. |
|
Codex Review: Didn't find any major issues. Another round soon, please! ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
The extra Dokka run was tied to the fuzzy `docs` token (which includes Markdown). Dokka does not process Markdown, so gate it purely on `.kt`/`.java` source presence in the diff — a code or KDoc/Javadoc-only edit. - pre-pr: proto-only stays `clean build` (Dokka appended only when `.kt`/`.java` also changed); Markdown-only needs no Gradle build; description and checklist reworded to say `.kt`/`.java` source, not "docs" (Copilot x3). - run-build.md: separate the Dokka decision from the base-command bullets so a proto-only or Markdown-only change no longer forces Dokka. - running-builds.md: document that Markdown-only changes need no Gradle build. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Per running-builds.md item 3, a KDoc/Javadoc-only edit inside a .kt/.java file should run dokkaGenerate alone - no compile, no tests. The earlier rule ran "build dokkaGenerate" for any .kt/.java change, an unnecessary build/test cycle for doc-only edits (Copilot x2). - pre-pr: split .kt/.java into code vs doc-only; doc-only -> dokkaGenerate (no build/tests); append dokkaGenerate only to a build target, and never double it when it is already the base command. - run-build.md: add the doc-only source bullet and the same don't-double note. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
pre-pr
pre-prbuildSrc and run Dokka in pre-pr
Why
A merge into
masterintool-basefailed its Publish to Maven repositories job indokkaGeneratePublicationHtml:The KDoc linked
KoverConfig, a type that lives only inbuildSrc— a separate compilation unit Dokka cannot see when documenting a published module. The link never resolved; Dokka is configured to fail on warnings, so the publish job broke even though./gradlew build(which does not run Dokka) passed locally.Why the existing tightening didn't catch it
buildSrc/. The offending doc used a symbol link whose package (io.spine.gradle.*) contains nobuildSrcsubstring — invisible to both reviewers and grep.review-docsis advisory;pre-prruns./gradlew build, which does not invoke Dokka. And the docs-only path used the baredokkatask, which is ambiguous under Dokka v2 and aborts — the real task isdokkaGenerate.Changes
guidelines/documentation.md— new section forbidding KDoc/Javadoc links ([Symbol],{@link},@see, …) tobuildSrc/configtypes, with the failure mechanism and a code-span fix.skills/review-docs/SKILL.md— matching Must-fix reviewer check; build hint →dokkaGenerate.skills/pre-pr/SKILL.md— appenddokkaGeneratewhenever code or docs changed (combined invocation); skip gracefully when Dokka isn't applied; a Dokka failure is a Must-fix.guidelines/running-builds.md,skills/writer/SKILL.md— replace the broken./gradlew dokkawithdokkaGenerate.Verification
./gradlew :plugin-testlib:dokkaGenerateintool-basereproduces the failure on stockmasterand passes once the doc link is demoted to a code span.Reach
These files float org-wide via
.agents/shared, so the rule and thepre-prDokka step apply to every Spine repo on the next pull. Repos without Dokka are unaffected (the step skips gracefully);build/deps-only diffs still run plainbuild.🤖 Generated with Claude Code