ci: fix devhub-validation by building DevHub with pnpm - #499
Open
pkosiec wants to merge 5 commits into
Open
Conversation
DevHub is a pnpm-only repo (commits only pnpm-lock.yaml, packageManager pnpm@10.11.0). The devhub-validation job installed it with `npm install`, which ignores the committed lock and does a floating, non-reproducible resolve on every run. A transitive dep publishing overnight was enough to shift the hoist and pull @databricks/appkit-ui/react into Next's react-server graph, crashing `next build` with `TypeError: b.createContext is not a function` on a job that passed the day before with no source change. Build DevHub the way DevHub's own CI does: pnpm install --frozen-lockfile and pnpm build. This makes the job reproducible and stops it silently mis-testing via a package manager DevHub never uses. Signed-off-by: Pawel Kosiec <pawel.kosiec@databricks.com>
Temporary docs-path touch so the docs path filter runs devhub-validation for the CI change in the previous commit. Safe to drop before merge. Signed-off-by: Pawel Kosiec <pawel.kosiec@databricks.com>
Passing an explicit version: input conflicts with this repo's packageManager field (pnpm@10.21.0), and action-setup errors out. Match the other jobs and omit version: so it reads packageManager. pnpm 10.x reads DevHub's lockfileVersion 9.0 fine. Signed-off-by: Pawel Kosiec <pawel.kosiec@databricks.com>
Contributor
🤖 AppKit PR bot🔬 Run evalsStart an eval for this PR from the evals-monitor app: Go to Evals Monitor → 📦 Try this PR's app templateScaffolds a new app from this PR's SDK build. Run it in any folder (requires the GitHub CLI — gh run download 30457270655 -R databricks/appkit -n appkit-template-0.48.0-pr.248ef67-pkosiec-fix-devhub-build-499 -D appkit-pr-499 \
&& unzip -o "appkit-pr-499/appkit-template-0.48.0-pr.248ef67-pkosiec-fix-devhub-build-499.zip" -d "appkit-pr-499" \
&& databricks apps init --template "appkit-pr-499"The template pins |
Signed-off-by: Pawel Kosiec <pawel.kosiec@databricks.com>
pkosiec
changed the title
pkosiec
marked this pull request as ready for review
July 29, 2026 13:41
pkosiec
commented
Jul 29, 2026
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
1 participant
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.
What
Build DevHub the way DevHub builds itself in the
devhub-validationjob:npm install→pnpm install --frozen-lockfilenpm run build→pnpm buildpnpm/action-setup(version read frompackageManager, matching the other jobs)Why
DevHub migrated from npm to pnpm (dropping
package-lock.jsonforpnpm-lock.yaml), but this job kept installing it withnpm install:@databricks/appkit-ui/react(a barrel) into Next's react-server (RSC) module graph. React 19'sreact-serverexport condition omitscreateContext, and a barrel-reachable module callscreateContextat top level →next buildcrashed on/_not-foundwithTypeError: b.createContext is not a function.pnpm install --frozen-lockfilepins the exact tree DevHub itself ships, so the job is reproducible again and can only go red on a real change — broken AppKit docs (the signal we want) or a genuine DevHub-side change.Notes
~/.npmrc, and DevHub's lockfile (v9.0) uses integrity-only resolutions (no baked registry URLs), so--frozen-lockfileis registry-agnostic./reactbarrel re-exports modules that top-level-callcreateContextwithout"use client". It only bites under an npm flat-hoist + RSC combo DevHub never uses, and this job compiles the published appkit-ui, not PR code — so fixing it here wouldn't change this job. Track separately.docs:commit only touches a readme to trigger the docs-gated job; drop before merge.This pull request and its description were written by Isaac.