ci(release_bundles): build lfx wheel locally for smoke test#13207
Merged
Conversation
The release_bundles.yml smoke test installs bundle wheels into a fresh venv, which makes uv resolve their `lfx>=X.Y,<Z` pin against PyPI. When bundles are released ahead of a matching lfx (typical case — bundles ship more often than lfx bumps land on PyPI), the resolve fails: Because only lfx<=0.4.3 is available and lfx-arxiv==0.1.0 depends on lfx>=0.5.0,<0.6.0, we can conclude that lfx-arxiv==0.1.0 cannot be used. Build the lfx wheel from the current ref in the build-bundles job and install it alongside the bundle wheels in the smoke test. The lfx wheel ships as a separate `dist-lfx-smoketest` artifact and is NOT included in the publish-bundles step — only the `dist-bundles` artifact gets pushed to PyPI.
Contributor
WalkthroughThe release workflow now builds an ChangesLFX wheel in release workflow
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Suggested labels
🚥 Pre-merge checks | ✅ 9✅ Passed checks (9 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #13207 +/- ##
==========================================
- Coverage 53.12% 53.02% -0.10%
==========================================
Files 2033 2033
Lines 184171 184171
Branches 26195 27710 +1515
==========================================
- Hits 97843 97662 -181
- Misses 85219 85400 +181
Partials 1109 1109
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.github/workflows/release_bundles.yml (1)
89-89: ⚡ Quick winConsider pinning GitHub Actions to commit SHAs for better supply-chain security.
Version tags on GitHub Actions (e.g.,
@v6,@v7) can be reassigned and represent a supply-chain risk. Pinning to full commit SHAs is a stronger security practice. Note that this workflow has multiple pre-existing unpinned actions; if enforcing this as a policy, consider addressing all of them consistently rather than only new additions.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/release_bundles.yml at line 89, Replace the unpinned action reference "uses: actions/upload-artifact@v6" with a pinned full commit SHA to mitigate supply-chain risk: locate the "uses: actions/upload-artifact@v6" entry in the workflow, find the corresponding commit SHA for the same release on the actions/upload-artifact repository (e.g., via GitHub's tag commit or release page), and update the line to "uses: actions/upload-artifact@<FULL_COMMIT_SHA>" so the workflow references an immutable commit; apply the same pinning approach to any other unpinned "uses:" entries if you plan to enforce this policy consistently.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In @.github/workflows/release_bundles.yml:
- Line 89: Replace the unpinned action reference "uses:
actions/upload-artifact@v6" with a pinned full commit SHA to mitigate
supply-chain risk: locate the "uses: actions/upload-artifact@v6" entry in the
workflow, find the corresponding commit SHA for the same release on the
actions/upload-artifact repository (e.g., via GitHub's tag commit or release
page), and update the line to "uses: actions/upload-artifact@<FULL_COMMIT_SHA>"
so the workflow references an immutable commit; apply the same pinning approach
to any other unpinned "uses:" entries if you plan to enforce this policy
consistently.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: cf1eb2b9-9905-489e-ab0f-cfbfbe00717a
📒 Files selected for processing (1)
.github/workflows/release_bundles.yml
Contributor
Frontend Unit Test Coverage ReportCoverage Summary
Unit Test Results
|
erichare
added a commit
that referenced
this pull request
May 19, 2026
… (#13210) * ci: stop publishing -nightly bundle variants; release bundles on demand (#13206) Bundles (lfx-arxiv, lfx-duckduckgo) change infrequently enough that a nightly cadence is overkill. Drop the rename-to-`-nightly` and bundle publish lanes from the nightly pipeline and add a dedicated workflow_dispatch-only release_bundles.yml for purposeful releases. - nightly_build.yml: drop update_bundle_versions.py invocation and the src/bundles/*/pyproject.toml git-add guard. - release_nightly.yml: remove build-nightly-bundles and publish-nightly-bundles jobs; untether test-cross-platform and publish-nightly-main from them. - release_bundles.yml (new): build all src/bundles/* wheels, run a cross-OS install smoke test, then publish to PyPI under their stable names. Tolerates already-published versions so re-runs without a version bump are no-ops. release.yml still owns bundle publishing as part of main releases. Manual follow-up (PyPI admin): delete the lfx-arxiv-nightly and lfx-duckduckgo-nightly projects from PyPI. * ci(release_bundles): build lfx wheel locally for smoke test (#13207) The release_bundles.yml smoke test installs bundle wheels into a fresh venv, which makes uv resolve their `lfx>=X.Y,<Z` pin against PyPI. When bundles are released ahead of a matching lfx (typical case — bundles ship more often than lfx bumps land on PyPI), the resolve fails: Because only lfx<=0.4.3 is available and lfx-arxiv==0.1.0 depends on lfx>=0.5.0,<0.6.0, we can conclude that lfx-arxiv==0.1.0 cannot be used. Build the lfx wheel from the current ref in the build-bundles job and install it alongside the bundle wheels in the smoke test. The lfx wheel ships as a separate `dist-lfx-smoketest` artifact and is NOT included in the publish-bundles step — only the `dist-bundles` artifact gets pushed to PyPI. * ci(nightly): re-pin bundle lfx deps to lfx-nightly during nightly build (#13208) The nightly pipeline renames the workspace `lfx` package to `lfx-nightly` in `src/lfx/pyproject.toml` and the root workspace dep, but leaves each `src/bundles/*/pyproject.toml`'s `"lfx>=X.Y,<Z"` pin unchanged. With the workspace `lfx` gone and PyPI still on lfx 0.4.3, the create-nightly-tag job's `uv lock` fails: × No solution found when resolving dependencies for split [...] ╰─▶ Because only lfx<=0.4.3 is available and lfx-arxiv depends on lfx>=0.5.0,<0.6.0, we can conclude that lfx-arxiv's requirements are unsatisfiable. `update_lfx_version.py` now also rewrites the `lfx` (or already-rewritten `lfx-nightly`) specifier in every `src/bundles/*/pyproject.toml` to `lfx-nightly==<dev version>`, mirroring how `update_lf_base_dependency` re-pins the lfx dep inside `langflow-base`. The lookahead in the regex prevents matching sibling packages like `lfx-arxiv` / `lfx-duckduckgo`. No-op when no bundle pyprojects exist (e.g. on main today), so this is safe to merge ahead of the bundle extraction landing on main. Restored the guarded `git add src/bundles/*/pyproject.toml` step so the modified bundle pyprojects ride the same commit/tag as the rest of the nightly version bumps. Cherry-pick to release-1.10.0 to unblock nightlies cut from that branch.
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.
Summary
The bundle smoke test in
release_bundles.ymlinstalls the freshly built bundle wheels into a clean venv, which makesuvresolve theirlfx>=X.Y,<Zpin against PyPI. When bundles are released ahead of a matchinglfx(the typical case — bundles ship more often thanlfxbumps land on PyPI), the resolve fails:Hit this trying to publish the first stable
lfx-arxiv/lfx-duckduckgooffrelease-1.10.0, which already haslfxat0.5.0locally butlfx 0.5.0isn't on PyPI yet.What changed
release_bundles.yml:lfxwheel from the current ref in thebuild-bundlesjob and upload it as a separatedist-lfx-smoketestartifact.test-install, download the lfx artifact and pass the lfx wheel + bundle wheels together touv pip install. The locallfxwheel satisfies the bundle pin, and remaining transitive deps resolve normally from PyPI.publish-bundlesis unchanged — it still only downloads thedist-bundlesartifact, so only bundle wheels get pushed to PyPI.Once this lands on
main, cherry-pick torelease-1.10.0to use the workflow from that branch (or trigger from main withrelease_tag=release-1.10.0).Summary by CodeRabbit