Conversation
Custom component checks will be done directly through the component index. Removing hash history as it no longer fits into any planned functionality.
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
WalkthroughThe changes comprehensively remove hash history build infrastructure and related components. This includes deleting the build_hash_history.py script, hash history build and merge jobs from the nightly GitHub workflow, related test files, the stable_hash_history.json asset, and hash history field handling from component metadata processing. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 7✅ Passed checks (7 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
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 Tip CodeRabbit can use your project's `ruff` configuration to improve the quality of Python code reviews.Add a Ruff configuration file to your project to customize how CodeRabbit runs |
Frontend Unit Test Coverage ReportCoverage Summary
Unit Test Results
|
Codecov Report❌ Patch coverage is
❌ Your project status has failed because the head coverage (44.41%) is below the target coverage (60.00%). You can increase the head coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## main #12183 +/- ##
==========================================
- Coverage 38.50% 38.48% -0.02%
==========================================
Files 1630 1630
Lines 80458 80456 -2
Branches 12152 12152
==========================================
- Hits 30977 30964 -13
- Misses 47731 47741 +10
- Partials 1750 1751 +1
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}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/nightly_build.yml:
- Around line 218-220: The workflow condition uses always() which bypasses
implicit success gating and only checks frontend-tests and backend-unit-tests
for != 'failure', allowing runs after cancelled/skipped jobs and not checking
create-nightly-tag at all; update the if expression to require explicit success
for all prerequisites (e.g., ensure needs.create-nightly-tag.result == 'success'
&& needs.frontend-tests.result == 'success' && needs.backend-unit-tests.result
== 'success') and remove the always() call so the release job only runs when
each listed need succeeded.
- Around line 237-242: Update the job-level if expression and the "Send failure
notification to Slack" step if expression to also check for the 'cancelled'
result alongside 'failure' and 'success'; specifically, add checks for
needs.release-nightly-build.result == 'cancelled', needs.frontend-tests.result
== 'cancelled', and needs.backend-unit-tests.result == 'cancelled' in the outer
job if and add the same 'cancelled' checks in the step's if so cancelled jobs
will trigger the Slack notification for the "Send failure notification to Slack"
step.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 9fe692ed-32fa-4e9a-9c06-193a16ce8bfd
📒 Files selected for processing (9)
.github/workflows/nightly_build.yml.secrets.baselineMakefilescripts/build_hash_history.pysrc/backend/base/langflow/initial_setup/setup.pysrc/backend/tests/unit/test_build_hash_history.pysrc/backend/tests/unit/test_initial_setup.pysrc/backend/tests/unit/test_starter_projects_no_hash_history.pysrc/lfx/src/lfx/_assets/stable_hash_history.json
💤 Files with no reviewable changes (7)
- src/backend/tests/unit/test_initial_setup.py
- scripts/build_hash_history.py
- src/backend/base/langflow/initial_setup/setup.py
- src/lfx/src/lfx/_assets/stable_hash_history.json
- Makefile
- src/backend/tests/unit/test_starter_projects_no_hash_history.py
- src/backend/tests/unit/test_build_hash_history.py
| if: github.repository == 'langflow-ai/langflow' && always() && needs.frontend-tests.result != 'failure' && needs.backend-unit-tests.result != 'failure' | ||
| name: Run Nightly Langflow Build | ||
| needs: [create-nightly-tag, frontend-tests, backend-unit-tests, build-hash-history] | ||
| needs: [create-nightly-tag, frontend-tests, backend-unit-tests] |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/nightly_build.yml | sed -n '210,250p'Repository: langflow-ai/langflow
Length of output: 2640
🌐 Web query:
GitHub Actions job result states needs condition always() function
💡 Result:
In GitHub Actions, jobs that use needs: are implicitly gated by a status-check: if your job-level if: expression doesn’t include a status-check function, GitHub automatically adds success()—so the job won’t run if any needed job failed/cancelled/skipped, even if your custom condition would otherwise be true. GitHub’s docs call this out: you must include a status-check function (like always(), failure(), etc.) to override that default behavior. [1]
That’s why you often see patterns like:
jobs:
downstream:
needs: [build]
if: ${{ always() && needs.build.result == 'skipped' }}always() forces evaluation even when needs.build didn’t succeed. [1]
If you don’t want the downstream job to run when the workflow is cancelled, use cancelled() in the condition (still counts as a status-check function), e.g.:
if: ${{ !cancelled() && (needs.build.result == 'success' || needs.build.result == 'skipped') }}needs.<job_id>.result can be success, failure, cancelled, or skipped. [2] And note that if: always() will keep running even during cancellation unless you guard against it. [3]
Sources
[1] GitHub Docs – Evaluate expressions / default success() behavior: https://docs.github.com/actions/writing-workflows/choosing-what-your-workflow-does/evaluate-expressions-in-workflows-and-actions
[2] GitHub Community (quoting docs) – needs.<job_id>.result values: https://github.com/orgs/community/discussions/45058
[3] GitHub Docs – Cancellation behavior and if: always(): https://docs.github.com/actions/reference/workflow-cancellation-reference
Require successful prerequisites before releasing; always() bypasses default dependency checks.
Line 218's condition uses always() and only excludes failure, but needs.<job>.result can also be cancelled or skipped. Because always() overrides the implicit success() check that normally gates dependent jobs, this allows release-nightly-build to proceed after a cancelled test job, or after a failed create-nightly-tag (which is never checked despite being listed in needs). To ensure releases only run after successful prerequisites:
Suggested guard
release-nightly-build:
- if: github.repository == 'langflow-ai/langflow' && always() && needs.frontend-tests.result != 'failure' && needs.backend-unit-tests.result != 'failure'
+ if: >-
+ github.repository == 'langflow-ai/langflow' &&
+ always() &&
+ needs.create-nightly-tag.result == 'success' &&
+ contains(fromJSON('["success","skipped"]'), needs.frontend-tests.result) &&
+ contains(fromJSON('["success","skipped"]'), needs.backend-unit-tests.result)
name: Run Nightly Langflow Build
needs: [create-nightly-tag, frontend-tests, backend-unit-tests]🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/nightly_build.yml around lines 218 - 220, The workflow
condition uses always() which bypasses implicit success gating and only checks
frontend-tests and backend-unit-tests for != 'failure', allowing runs after
cancelled/skipped jobs and not checking create-nightly-tag at all; update the if
expression to require explicit success for all prerequisites (e.g., ensure
needs.create-nightly-tag.result == 'success' && needs.frontend-tests.result ==
'success' && needs.backend-unit-tests.result == 'success') and remove the
always() call so the release job only runs when each listed need succeeded.
2 participants
Custom component checks will be done directly through the component index. Removing hash history as it no longer fits into any planned functionality.
Summary by CodeRabbit
Release Notes
Chores
Refactor