fix(ci): scope nightly migration-test pre-releases to the langflow stack
The previous fix (#13599) added a global --prerelease=allow, which let
UNRELATED dependencies resolve to alphas: on nightly run 27274206250
the stable->nightly upgrade pulled pydantic 2.14.0a1 + pydantic-yaml
1.6.1a1, and the pydantic alpha breaks langchain-core at import time
(RunnablePassthrough pydantic ValidationError), failing the nightly
boot right after a successful install. Clean installs were fine - only
this upgrade path resolved the alpha combo.
Scope pre-release eligibility to the langflow lockstep stack instead:
uv accepts a pre-release when the package's own requirement carries a
pre-release marker, but not via transitive pins, and the nightly chain
is langflow -> langflow-base -> lfx -> langflow-sdk with exact ==devN
pins. Request each directly; langflow-sdk versions independently
(0.2.0.devN), so an explicit .dev0 floor marks it eligible while lfx's
exact pin selects the version. The 'latest' branch gets the same
treatment via .dev0 floors on all four.
Verified by dry-run against PyPI: langflow/langflow-base/lfx at
1.11.0.dev2 + langflow-sdk 0.2.0.dev2 resolve with pydantic staying at
stable 2.13.4.
fix(ci): allow pre-releases when pinning the nightly in migration validation
Migration Test: pip/venv (stable -> nightly) failed deterministically on
nightly run 27260425158 (twice, including a rerun):
hint: langflow-base was requested with a pre-release marker (e.g.,
langflow-base==1.11.0.dev1), but pre-releases weren't enabled
(try: --prerelease=allow)
This is the first nightly publishing as a canonical .devN pre-release
of the langflow distribution (nightly -> stable bundle cutover). The
'latest' branch of the upgrade step already passes --prerelease=allow,
but the pinned-version branches do not. uv implicitly allows the
pre-release for the directly requested ==X.Y.Z.devN pin, yet langflow's
metadata pins langflow-base==X.Y.Z.devN transitively, and uv rejects
transitive pre-releases unless they are enabled - so the install fails
after the stable uninstall, sinking the migration test.
Add --prerelease=allow to both pinned-version install lines.
* docs: record nightly→stable bundle cutover plan (gated on lfx 1.10.0)
Add src/bundles/NIGHTLY.md documenting why langflow-nightly currently
renames the bundles (lfx and lfx-nightly ship the same lfx/ import, so a
stable bundle would co-install both and collide) and the deferred cutover
(Approach A: canonical pre-releases; B: lfx as a bundle extra), gated on
stable lfx 1.10.0 being published to PyPI.
Also expand two docstrings in scripts/ci/update_lfx_version.py to state
the deeper install-conflict reason, not just the resolve failure. No
behavior change.
* feat(ci): nightly Approach A — canonical pre-releases, drop nightly bundles [DRAFT/gated] (#13529)
feat(ci): nightly Approach A — canonical pre-releases, drop nightly bundles
DRAFT reference implementation of the nightly→stable-bundle cutover documented
in src/bundles/NIGHTLY.md. Publishes the nightly under CANONICAL package names as
.devN pre-releases instead of separate *-nightly distributions, so the stable
lfx-* bundles resolve against a single canonical lfx (no dual-lfx install
collision) and no nightly bundle packages are produced.
- tag scripts (pypi/lfx/sdk_nightly_tag.py): count .devN against the canonical
PyPI histories instead of the *-nightly projects
- update scripts: stop renaming to *-nightly; set .devN versions; re-pin
inter-package deps to exact canonical dev versions; delete the bundle
rename/repin (update_lfx_dep_in_bundles, rename_bundles_for_nightly)
- release_nightly.yml: publish canonical pre-releases; remove bundle build,
dist-nightly-bundles artifact, publish-nightly-bundles job + its gate; verify
canonical names; main wheel glob dist/langflow-*.whl
- nightly_build.yml: drop the bundle git-add in the tag commit
- NIGHTLY.md: Approach A marked implemented + activation gate + A1/A2 follow-ups
Held as DRAFT: do not activate until stable lfx 1.10.0 is published AND the
nightly base is the next minor (release-1.11.0). A 1.10.0.devN core sorts below
1.10.0 and would fail the bundles' >=1.10.0 floor. Stacked on #13528.
(.secrets.baseline: incidental line-number shifts for the two workflows + prune
of pre-existing stale Pokédex Agent.json entries.)
* docs(ci): drop internal 'Approach A' label from nightly cutover comments
Comment- and docstring-only change across scripts/ci/* and the two nightly
workflows; no logic change. The two workflow edits stay single-line so
.secrets.baseline line numbers are unaffected. src/bundles/NIGHTLY.md keeps
its A/B decision-record framing intentionally.
* feat(ci): make nightly consumers work with canonical pre-releases
Follow-ups from the nightly cutover that are part of its blast radius (the
nightly now publishes canonical `.devN` pre-releases, not `*-nightly`
distributions):
- version.py: derive the "Nightly" label from the `.dev` version marker, since
the canonical `langflow`/`langflow-base` distribution matches first in the
lookup. Keeps the startup banner and telemetry `package` field identifying
nightlies. Adds a canonical-dev test; updates the base-dev assertion.
- ci.yml check-nightly-status: query the canonical `langflow` project and pick
the latest `.devN` release date instead of `langflow-nightly`'s `.info.version`.
- db-migration-validation.yml: install the nightly as `langflow[postgresql]==<dev>`
(pre-release) instead of `langflow-nightly[...]`; verify via version("langflow").
- src/lfx/README.md: nightly install is `uv pip install --pre lfx`.
- NIGHTLY.md: rewrite the follow-ups section (these are addressed; Docker image,
A2 meta-package, and website docs remain deferred by design).
The `langflowai/langflow-nightly` Docker image name is intentionally unchanged.
* fix(ci): correct nightly verify uv tree parsing + stale base-dep regex
Addresses review of #13528:
- release_nightly.yml LFX verify: `uv tree | grep lfx | head -n1` matches the
bundle `lfx-ibm` first → 'Name lfx-ibm does not match lfx'. Root the tree with
`uv tree --package lfx` so the first line is the lfx package itself.
- release_nightly.yml base verify: under canonical naming `langflow-base` prints
as a top-level `langflow-base v<ver>` line, so the old $2/$3 field parse read
name="v0.10.0" and version="". Use `uv tree --package langflow-base` and $1/$2.
- update_lf_base_dependency.py update_base_dep: regex only accepted ~=/==, so its
CLI entry point couldn't match the current root dep `langflow-base[complete]>=0.10.0`.
Add >= (parity with update_uv_dependency.py). The active nightly path uses
update_uv_dependency.py and was unaffected.
* docs(nightly): point NIGHTLY.md status at the activation gate, not draft state
Per review of #13528: this file ships inside #13528 (#13529 was folded in), so
the 'stacked on prep #13528' + 'held as a draft' framing is stale and misleading.
Reword the status block to state the real guard is the activation gate (stable
lfx 1.10.0 published AND next-minor base), not merge/draft state. Also reword the
follow-ups heading 'decide before un-drafting' -> 'decide before activating'.
fix(ci): re-enable migration-pip-venv now that nightly bundles resolve
The PyPI langflow-nightly is pip-installable again, so the temporary
`if: false` guard added on 2026-05-28 is no longer needed.
#13418 (release-1.10.0) and its forward-port #13419 (main) gave the
extension bundles their own nightly track: langflow-nightly now depends on
lfx-arxiv-nightly / lfx-duckduckgo-nightly / lfx-ibm-nightly, which pin
lfx-nightly==0.5.0.dev* instead of an unsatisfiable stable lfx>=0.5.0,<0.6.0.
Verified against the published dev57 wheels: a dry-run resolve of
langflow-nightly[postgresql] succeeds (549 packages, exit 0), pulling
lfx-nightly==0.5.0.dev57 via the *-nightly bundle variants.
The PyPI langflow-nightly is currently pip-uninstallable: its core bundle
deps (lfx-arxiv, lfx-duckduckgo) pin stable lfx>=0.5.0,<0.6.0, but stable
lfx tops out at 0.4.4 (the 0.5.0 line ships only as lfx-nightly, a separate
package name that cannot satisfy an lfx pin). So the pip/venv migration job
fails at the install step.
The Docker Compose migration job is unaffected (it runs the prebuilt nightly
image) and stays enabled. Re-enable once either a stable lfx 0.5.x is
published to PyPI or nightly bundle variants pinning lfx-nightly are
published and langflow-nightly depends on them.
* ci: port safe workflow fixes from release-1.10.0 to main
Reconciles the workflow/CI improvements that landed on release-1.10.0 back
into main, EXCLUDING workflows that depend on release-only features not yet
present on main.
Ported (verified no release-only dependencies):
- test-coverage-advisor.yml (new; advisory-only, fully self-contained)
- ci.yml, nightly_build.yml, db-migration-validation.yml (incl. the #13249
enhancements), python_test.yml (Python 3.14 support), cross-platform-test.yml
(--prerelease=if-necessary-or-explicit), lint-js.yml, py_autofix.yml,
typescript_test.yml
Held back (depend on features that only exist on release-1.10.0):
- extension-migration-checks.yml (extensions / src/bundles / scripts/migrate)
- gp-backend-check.yml (release-only scripts/gp/*.py + backend locales/en.json)
- regression-stub.yml (release-only regressions/ tracking)
- gp-download.yml / gp-upload.yml backend-translation steps
(release-only scripts/gp/{download,upload}.py)
These converge with main once release-1.10.0 ships. 3-way merged from the
common ancestor; the diff was verified to introduce zero references to
release-only paths.
* test: add cache_dir to Settings EXPECTED_FIELDS snapshot
The diskcache-removal change added a `cache_dir` field to the cache settings group,
but the field-count guard in test_settings_composition.py (EXPECTED_FIELDS, frozen by
the settings split in #13141) was never updated. As a result test_field_count_unchanged
failed on main with `assert 106 == 105`. Add "cache_dir" to the snapshot so it matches
the live Settings model (106 fields).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* feat: Add DB migration validation workflow for nightly builds (LE-1259)
- Implements automated DB migration testing for nightly builds
- Tests two scenarios: pip/venv and Docker Compose migrations
- Validates migration from stable to nightly versions
- Verifies data persistence (witness flows) across migrations
- Integrated into nightly_build.yml workflow
- Includes Slack notifications for migration test results
This addresses the critical blocker identified by QA team for ensuring
safe database migrations in production deployments.
* docs: Add DB migration validation documentation
- Comprehensive guide for LE-1259 implementation
- Detailed test scenarios and execution details
- Environment configuration and success criteria
- Monitoring and troubleshooting guidelines
- Placed in docs/docs/Deployment/ for easy access
* fix: address PR review comments for DB migration validation
- Use actual nightly tag from create-nightly-tag output instead of hardcoded :latest
- Wire POSTGRES_VERSION env var into postgres service image tag
- Remove unnecessary checkout steps from both migration jobs
- Update step name from 'Create witness flow and credentials' to 'Create witness flow'
- Add -f flag to curl commands for fail-fast behavior
- Add flow creation verification with error handling
- Fix version extraction logic to properly test nightly build instead of PyPI latest
- Remove deprecated docker-compose version field
- Remove duplicate Slack notification job (consolidated in nightly_build.yml)
Addresses all 9 issues identified by @ogabrielluiz in PR review
* docs: remove implementation summary from user-facing docs
Per @ogabrielluiz review feedback, this file reads as an implementation
summary (Jira ticket, branch name, 'Next Steps', 'Files Changed: 2')
rather than user-facing documentation. The Deployment section is for
end-user docs, and this content is better suited for the PR description.
Also not added to sidebars.js, so would be an orphan page.
* fix(workflows): address 6 issues from Gabriel's second review of DB migration validation
Fixes all remaining issues identified in PR #13249 review:
1. Remove schedule trigger - only works on default branch, would cause duplicate runs
2. Fix postgres service image - hardcode to postgres:16 (env context not available in services)
3. Add curl fail-fast flags - use -fsSL for immediate failure on errors
4. Add flow ID verification - check witness data creation succeeded before proceeding
5. Remove orphaned Slack JSON - cleanup leftover from removed notify-results job
6. Fix version extraction - strip 'v' prefix for pip install (${VERSION#v})
7. Fix Docker image reference in nightly_build.yml - pass full image path with tag
8. Fix success notification - check migration validation didn't fail
All changes validated locally:
- YAML syntax validation passed
- Docker Compose config validated
- Tag manipulation logic tested (v prefix handling)
- Curl command structure verified
- Test credentials marked with pragma allowlist secret comments
Related: LE-1259, PR #13249
Depends on: PR #13212 (Docker volume permissions fix)
