The create_release job tagged the release with determine-main-version's
output, which strips the v prefix, and passed no commit. ncipollo then
created a bare vless tag (e.g. 1.10.0) at the default branch HEAD instead
of the validated source tag (v1.10.0). GitHub generateReleaseNotes
compared that bare tag against the previous bare tag, so the changelog
only captured PRs merged directly to main and missed everything that
shipped through the release branch.
Tag the release on inputs.release_tag and pin the commit to it. This is
the same vless-duplicate-tag failure the validate-tag-format job already
warns about.
fix: remove duplicate uv.lock from workspace member
Forward-port of #13326 to main. The monorepo should keep only one
uv.lock at the workspace root; src/backend/base/uv.lock was a stale
duplicate. The scheduled nightly build runs from main's workflow
definition, so create-nightly-tag still ran
`git add ... src/backend/base/uv.lock` against a tree where the file
no longer exists, failing with exit 128.
- Delete src/backend/base/uv.lock
- nightly_build.yml: drop base-dir `uv lock` regeneration and the
base lockfile from `git add`
- Remove COPY/bind-mount of the base lockfile from all Dockerfiles
- Makefile: lock_base/lock now lock only the root workspace
- changes-filter.yaml: drop the base lockfile path
- .secrets.baseline: shift nightly_build.yml line number 305 -> 304
Fixes the failing nightly:
https://github.com/langflow-ai/langflow/actions/runs/26699469476
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.
Forward-port of #13418 (merged to release-1.10.0) to main, so a nightly
dispatched off main uses workflow definitions that publish the bundles.
The nightly builds the resolved release branch's code, but the workflow
files (release_nightly.yml) are read from the dispatch ref, so main needs
the publish-nightly-bundles job too.
Background: the nightly tagger renames lfx -> lfx-nightly, but the
extension bundles were published as stable lfx-<name> wheels pinning
lfx>=X.Y, so langflow-nightly dragged in a stable lfx that only exists as
lfx-nightly -> unsatisfiable. Give the bundles their own nightly track:
- update_lfx_version.py renames each src/bundles/* package to
lfx-<name>-nightly, versions it <base>.dev<N>, and repoints the root
langflow deps + [tool.uv.sources] entries. (No-op on main until bundles
are declared there; kept in lockstep with release-1.10.0.)
- release_nightly.yml publishes the nightly bundle wheels and gates
publish-nightly-main on them.
fix(ci): lockstep langflow-nightly and langflow-base-nightly versions
Forward-port of #13413 (merged to release-1.10.0) to main.
pypi_nightly_tag.py now derives a single shared dev number from
max(dev across BOTH langflow-nightly and langflow-base-nightly PyPI
histories) + 1 (restricted to the root base_version) and emits it twice in
`both` mode. nightly_build.yml reads the release and base tags from one
invocation (single PyPI snapshot) and fails closed on mismatch, so the latest
langflow-nightly always pins a langflow-base-nightly[complete]==X.Y.Z.devN
that was built and published in the same run (no more uninstallable nightly).
Safe to land now: the nightly create-nightly-tag job checks out the latest
release-* branch for the script while taking the run-block from the triggering
ref (main for scheduled runs). release-1.10.0 already carries the new script
(via #13413), so main's `both` run-block matches it, and future release
branches cut from main inherit the lockstep script.
Adds scripts/ci/test_pypi_nightly_tag.py + .github/workflows/ci-scripts-test.yml
and the update_pyproject_combined.py lockstep-invariant note.
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)
* refactor(settings): split monolithic Settings into per-domain group mixins
Move the ~70-field Settings class from one 755-line base.py into 13 cohesive
BaseModel mixins under lfx/services/settings/groups/ (paths, server, database,
cache, storage, mcp, telemetry, observability, security, components, ui,
runtime, variables). Settings now composes them via multiple inheritance.
Inheritance order is chosen so cross-group validators see their dependencies
in info.data: PathSettings rightmost (config_dir before database_url),
ServerSettings just left of it (workers before event_delivery).
No env var or call-site changes. BASE_COMPONENTS_PATH re-export preserved for
tests that import it transitively.
* [autofix.ci] apply automated fixes
* [autofix.ci] apply automated fixes (attempt 2/3)
* docs(settings): fix wrong mcp_server_timeout docstring and idle-timeout comment
mcp_server_timeout's docstring was copy-pasted from a database setting and
mentioned 'lock to released' / 'database connection'. Replace with text that
describes the actual field.
mcp_session_idle_timeout's comment said 'Defaults to 5 minutes' but 400s is
~6.7 minutes. Drop the misleading 'minutes' claim and keep the value.
* test(settings): add structural safety tests for the group composition
Adds 26 tests to guard the refactor:
- All 105 fields that lived on the monolithic Settings still exist on the
composed class. A missing group in the inheritance list trips this loudly.
- A sampling of critical scalar and dict defaults (host, port, workers,
cache_type, sqlite_pragmas, db_connection_settings, etc.) are byte-for-byte
unchanged.
- Cross-group validator dependencies still resolve via info.data:
workers > 1 forces event_delivery=direct (ServerSettings -> RuntimeSettings)
and database_url falls back to a sqlite path under config_dir without
raising 'config_dir not set' (PathSettings -> DatabaseSettings).
- A parametrized sweep verifies a representative set of LANGFLOW_* env vars
still populate their fields.
- Back-compat exports (CustomSource, is_list_of_any, yaml helpers,
BASE_COMPONENTS_PATH) are still importable from settings.base.
- update_settings handles scalars and list-with-no-duplicates correctly.
- save_settings_to_yaml round-trips without error.
* [autofix.ci] apply automated fixes
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
