[dependabot]

Bumps cubrid-lab/cubrid-cookbook-python/.github/workflows/smoke-test.yml from b23252c7552f9dbf09f8c1e27474f0d384f7a7b5 to 50e5d34270aec5b3f00d1b411386ddbe63b25922.

Changelog

Sourced from cubrid-lab/cubrid-cookbook-python/.github/workflows/smoke-test.yml's changelog.

Changelog

All notable changes to this project will be documented in this file.

The format is based on Keep a Changelog.

Tags v0.1.0 and v0.2.0 predate this file and have no sections.

[Unreleased]

Upgrade notes

• The templates/api-service-fastapi and templates/dashboard Compose files publish only on localhost (#469) — the CUBRID broker (33000, whose lab dba account has no password) is now 127.0.0.1:33000, and the API (8000) and the Streamlit dashboard (8501) default to 127.0.0.1 too, so a stack started from an earlier file stops answering from other machines. Your browser on the same host is unaffected. To expose the application on purpose, set API_HOST_IP=0.0.0.0 (API) or DASHBOARD_HOST_IP=0.0.0.0 (dashboard) when you run docker compose up; the broker has no such switch. The API template's CUBRID service also gains the named volumes cubrid_data and cubrid_databases: the first docker compose up after updating starts from an empty database (the old data stays in the unnamed volumes of the earlier containers until you remove them), after which docker compose down keeps the data and only docker compose down -v deletes it.
• The recipe Compose files no longer fix a host or container name, so a volume created by an earlier file needs a one-time recovery (#463) — quickstart/5min-fastapi, quickstart/5min-sqlalchemy, templates/api-service-fastapi and templates/dashboard drop hostname: (cubrid-fastapi, cubrid-sqlalchemy, cubrid-api-service, cubrid-dashboard) and container_name: (cubrid-db, fastapi-service, cubrid-dashboard) and set CUBRID_DB_HOST: localhost on the CUBRID service, as the root lab does since #436. A database created by an earlier file still names its old host in databases.txt and fails to open with -353 in the new container; the data is kept. In that recipe's folder, apply the recovery from GETTING_STARTED.md ("A lab created before the October 2026 lab changes"): docker compose up -d cubrid, rewrite the host to localhost in databases.txt with the sed command shown there, docker compose restart cubrid, then start the stack. Each recipe README repeats these steps. Do not run docker compose down -v to recover; it deletes the data. Containers are now named by Compose, so address them as services (docker compose exec cubrid ..., docker compose logs cubrid); the dashboard upgrade commands that used docker inspect cubrid-dashboard now use docker compose ps -aq cubrid.
• The root lab no longer has a fixed container name or host name, so an existing lab needs a one-time recovery (#436) — docker-compose.yml drops container_name: cubrid-cookbook and hostname: cubrid-cookbook and sets CUBRID_DB_HOST: localhost, which registers a new database for localhost. The container is now named by Compose (for example cubrid-cookbook-python-cubrid-1): address it as the service, docker compose exec cubrid ..., instead of by the old container name. A database created by an earlier file still names its old host (cubrid-cookbook or a container ID) in databases.txt and fails to open with -353 in the new container; the data is kept, and GETTING_STARTED.md ("A lab created before the October 2026 lab changes") gives the recovery: rewrite the host to localhost and restart, after first copying an 11.4 database from its unnamed volume if the lab predates #385. Do not run make docker-clean or docker compose down -v to recover; they delete the data.
• make clean, make check and make verify VERIFY_PATHS=... changed meaning (#437) — make clean now removes only generated files, caches and test results (.live-evidence/, __pycache__, .pytest_cache, .ruff_cache, the staged docs pages and site/) and never touches Docker; to delete the lab's containers and volumes, database data included, run the new make docker-clean (make down still stops the lab and keeps the data). make check is now the non-test quality gate (lint, format-check, check-docs, check-coverage) and no longer runs the offline tests: run make check test for the full offline gate, as CI now does. make lint runs only ruff check; ruff format --check moved to the new make format-check, and the new make format is the only target that rewrites files. make verify VERIFY_PATHS=<dirs> on the command line, kept as the golden-only check in #416 / #434, now fails with a one-line message: run make verify-goldens VERIFY_PATHS=<dirs> instead. A bare make verify (an exported VERIFY_PATHS included) is unchanged, the full live verification.
• make verify is now the full live verification (#416) — the golden-only check that make verify ran before is now make verify-goldens (make verify VERIFY_PATHS=<dirs> on the command line still runs only those goldens). A bare make verify also runs every live pytest suite and needs two dedicated, empty CUBRID databases in CUBRID_TEST_URL and CUBRID_DASHBOARD_TEST_URL besides the make up database; CONTRIBUTING.md ("Live verification") shows how to start them. Run make deps again first: it now installs every example's requirements and pytest-asyncio.
• A local lab started from the earlier docker-compose.yml needs a one-time recovery (#385) — the new lab file recreates the cubrid-cookbook container with a fixed host name and named volumes, and an existing database then fails to open with -353, because CUBRID recorded the old host name. The data is kept: GETTING_STARTED.md ("A lab created before the October 2026 lab fix") gives the tested recovery for a default 11.2 lab (rewrite the host in databases.txt, then restart) and for an 11.4 lab (copy the database from its unnamed volume into the new named volume first). Do not use docker compose down -v to recover; it deletes the data.

Added

• Live runs write test-results/verify/ with one versioned summary (#462) — make verify and every make verify-* lane (scripts/live_gate.py) now also write test-results/verify/ (ignored by git, removed by make clean) with the scripts/report_results.py helpers that make test uses: summary.json (schema_version, an overall status of PASS, FAIL or INCOMPLETE, scope/partial, total counts, and per lane its status, whether it executed, counts, JUnit file, logs and reasons; a lane that never ran is INCOMPLETE, "executed": false and in not_run), environment.json (command, Python and platform, package versions, CUBRID server versions with password-hidden URLs, commit, CI run identifiers), one merged JUnit file per pytest lane under junit/<lane>.xml, the lane logs under logs/<lane>/ and summary.md, a Markdown rendering for a CI step summary. The last console line is built from summary.json. make verify starts from an empty directory; a focused lane replaces only its own files and merges the other lanes recorded for the same commit, so consecutive lanes end with one partial summary. Passwords from CUBRID_TEST_URL and CUBRID_DASHBOARD_TEST_URL (raw, percent-encoded or XML-escaped) are now replaced with *** in every file of test-results/verify/ and .live-evidence/, and a test pins that none reaches a result file. .live-evidence/ keeps its layout, files and exit codes for at least one release because smoke-test.yml and the pull-request smoke jobs read and upload it.
• make test writes JUnit files and a versioned summary.json (#461) — every run of the offline suites now writes test-results/test/ (ignored by git, removed by make clean): one JUnit file per suite under junit/ and summary.json with schema_version, a status of PASS, FAIL or INCOMPLETE, totals and per-suite counts (selected, passed, failed, errors, skipped, xfailed, xpassed, each test counted once with its worst outcome), the suites not run after a failure, and "coverage": {"measured": false}. The run ends with a one-line summary built from the same data. pytest suites use --junitxml; the unittest suites run through the new scripts/unittest_junit.py, which keeps the console output and exit status of python -m unittest and writes the same JUnit shape; the shell-script suite counts as one check. The offline suites measure no coverage, so no coverage.xml is written and no coverage gate is added. The suite list, console output, stop-at-first-failure behavior and exit status are unchanged; scripts/report_results.py (stdlib XML parsing, like scripts/live_gate.py) is reusable by the live side, and tests/test_report_results.py joins make test. CI does not publish the files yet.
• CUBRIDdb-to-pycubrid migration guide with four runnable recipes (#445) — the new migration/cubriddb-to-pycubrid/ lesson moves a Python application from the official CUBRIDdb C-extension driver to pycubrid, separately from the Java-to-Python guide. Its README covers installation (a pinned cubrid-python source build versus pip install pycubrid, and why the 2014 CUBRID-Python 9.3.0 PyPI archive is no substitute), connection mapping (CCI DSN to keyword arguments, default user public versus dba, autocommit ON versus OFF, threadsafety 2 versus 1, charset), parameter handling (CCI typed binding versus driver-side literal conversion, the pycubrid 1.12 opt-in executemany(..., prepared=True) batch), rows, LOBs, errno/code/sqlstate versus the official args tuple, transaction failures, disconnects with an unknown outcome, the native features ordinary pycubrid does not offer, and decision points that link the dated cubrid-benchmark comparisons without quoting numbers. Official-driver statements are read from cubrid-python v11.3.0.51 and labelled as not run; there is no drop-in or full CCI parity claim. 01_connection_mapping.py, 02_parameterized_crud.py, 03_fetch_and_errors.py and 04_transaction_visibility.py each create a marked cookbook_cdb_* table, refuse to touch an unmarked table of the same name, and drop their table in finally; their goldens run in make verify (pycubrid>=1.6.1, same output on 1.6.1 and 1.13.1). The guide is linked from README.md, llms.txt, GETTING_STARTED.md and the site navigation (staged as migration-cubriddb-to-pycubrid), with a Korean translation in docs/ko/migration-cubriddb-to-pycubrid.md. SUPPORT_MATRIX.md gains a "CUBRIDdb-to-pycubrid migration" row (4 recipes; 105 in total, 69 golden-backed), and THIRD_PARTY_LICENSES.md lists the new requirements.txt.
• Partial golden and lane runs are labeled PARTIAL (#460) — make verify-goldens (scoped by VERIFY_PATHS or not) now ends with PARTIAL: checked only the goldens under: <roots> after the unchanged Results: line, and a focused lane (make verify-quickstart, verify-performance, verify-web, verify-django-celery, verify-ai-agent, verify-dashboard, verify-templates) prints PARTIAL: checked only the <lanes> lane(s), repeats it in its summary.txt and records "partial": true in .live-evidence/<lane>/summary.json. The full make verify is the only run that records "partial": false (in its lane summaries and verify-summary.json) and its goldens part prints no PARTIAL line (scripts/verify_goldens.sh reads VERIFY_SCOPE=full, set only by scripts/live_gate.py all; an ambient value is ignored). No golden or suite is added, removed or skipped. tests/test_live_gate.py and tests/test_make_commands.py pin the label, the evidence field and that a scoped run cannot carry the full marker.
• FastAPI quickstart GET /health and live CRUD tests (#420) — quickstart/5min-fastapi/app.py gains GET /health, which runs SELECT 1 FROM db_root on a new connection and returns {"status":"ok","database":"ok"}, or HTTP 503 with {"status":"error","database":"unavailable"} and no error details when the database cannot be reached. The mocked suite covers both answers. The new quickstart/5min-fastapi/tests/test_live.py drives the app with TestClient against a running CUBRID named by CUBRID_TEST_URL and checks each answer against the table through a separate pycubrid connection: startup and /health, POST /items with the committed row, GET /items and GET /items/{id}, 404 for a missing id, 422 for three invalid bodies with no row written, a rejected over-long insert that leaves no row, and 503 from a real connection attempt to a closed port. get_conn() now passes connect_timeout=10, so /health answers 503 instead of hanging on an unreachable host. Tests write only rows marked with a random live-qs- prefix and delete exactly those, so repeated runs pass. make test leaves test_live.py out, so it never needs or writes to a database; run on their own, the live tests skip without CUBRID_TEST_URL, while a configured but unreachable database fails. make verify-quickstart (and the full make verify) runs them with CUBRID_LIVE_GATE=1 (a missing URL also fails) and writes JUnit and a summary to .live-evidence/quickstart/ (ignored by git). The quickstart README, its Korean page and SUPPORT_MATRIX.md document the endpoint and the command. CI does not run the live suite yet.
• Release verification also runs on Python 3.11 (#238) — smoke-test.yml takes the Python version from a new python matrix axis (["3.12"]). A release verification (repository_dispatch, a workflow_dispatch pinned to a package, or a workflow_call from a driver's release workflow) adds exactly one cell, CUBRID 11.4 on Python 3.11, the supported minimum, running the same full job (make verify, AI-agent, Flask/FastAPI, async-worker, Django and dashboard suites, offline guards). Push to main, the daily schedule and latest-release manual runs keep the two Python 3.12 cells, so no schedule and no other run costs more; the release adds one job (about the length of an 11.4 cell). The caller contract is unchanged: same inputs and outputs, the existing job names (Smoke Tests (CUBRID 11.2) / (CUBRID 11.4)) and artifact names stay, the new cell is Smoke Tests (CUBRID 11.4, Python 3.11) with the artifact release-verification-part-cubrid-11.4-py3.11. Each report matrix entry gains a python field (scripts/release_smoke.py summary --python), and a failure reason names the cell (CUBRID 11.4, Python 3.11: …); a release report now also fails unless exactly the three expected cells (11.2/3.12, 11.4/3.12, 11.4/3.11) each reported once, naming any missing, duplicate or unexpected cell, and every cell must have passed with the requested version (this also closes the earlier gap where a missing 11.2 or 11.4 part went unnoticed); non-release runs are unchanged, and the Python is left out of a cell name for the default 3.12. Job hygiene is unchanged (60-minute timeout, pinned actions, persist-credentials: false, contents: read). tests/test_release_verification.py and tests/test_release_dispatch.py fail if the extra cell is wrong or unconditional, the expected cell set drifts from the workflow matrix, a cell is missing or duplicated, the report matrix is not sorted, summary --python is not recorded, the Python is hard-coded again, the artifact names collide, or inputs. reaches a step. CONTRIBUTING.md and SUPPORT_MATRIX.md describe the cell.
• Stricter guard tests for the driver lanes (#239, #241 review follow-up) — tests/test_ci_scope.py now asserts exact lines instead of substrings: the caller's if: github.event_name == 'schedule', the activity-guard comparison (-ge "$ACTIVE_DAYS"), ACTIVE_DAYS: "8", the commit check ok &= got == want and the report job's default-branch clause. A new test ties the driver-main.yml RECIPES list to the directories of scripts/driver_floors.py FLOOR_SETS (parsed, not hard-coded), so both lanes cover the same recipes. The workflow comment and CONTRIBUTING.md document that an open tracking issue is closed only by the next run that executes, and that a manual dispatch closes it when both drivers are idle. No workflow logic changed.
• Whole-second timestamps normalize like fractional ones (#265) — scripts/normalize_output.sh now maps {{DATE}} HH:MM:SS and {{DATE}}THH:MM:SS with no fractional part to {{DATETIME}}, so goldens such as fundamentals/pycubrid/09_serial_order_numbers.py no longer fail about 1 run in 1000 when a DATETIME lands on .000 and Python's str(datetime) drops the fraction. Values followed by a UTC offset, Z or an uppercase zone name (the fixed 20_timezone_datetime outputs) stay unscrubbed, and every existing golden normalizes unchanged. scripts/test_normalize_output.sh covers whole-second, millisecond and microsecond variants for both separators.
• Documented driver floors are installed and run, not only checked as text (#241) — the new Driver floors (CUBRID 11.4) job in ci.yml runs scripts/driver_floors.py, which installs every documented pycubrid/sqlalchemy-cubrid floor exactly (==, read from the recipes' own requirements.txt) in one virtual environment per floor set and diffs 60 representative goldens against live CUBRID 11.4 on Python 3.12: the global floor (pycubrid==1.6.1, sqlalchemy-cubrid==1.0), the advanced SQLAlchemy floor (1.4.2, fundamentals/pandas), fundamentals/async, the 1.7 line (fundamentals/connect, orm-basics, lob-handling), the 1.9 line (fundamentals/pycubrid, fundamentals/sqlalchemy) and fundamentals/alembic. It is one job (about 3 minutes) selected by pull requests that change SUPPORT_MATRIX.md, the floor checker or lane, or a lane directory's requirements.txt, by the existing weekly ci.yml schedule and by manual ci.yml runs; it does not run on pushes to main, adds no schedule and is enforced by CI Gate only when selected. The golden directories without a requirements.txt (fundamentals/crud, error-handling, lob-handling, transactions) are now covered, and scripts/check_dependency_floors.py accepts extras (sqlalchemy-cubrid[pycubrid]>=1.0) and spaced specifiers. tests/test_dependency_floors.py fails when a documented floor is not installed by any floor set, a directory-specific floor runs on another directory, the lane pins drift from the requirements, or a floor change would not select the lane. Floors raised where the lane failed: fundamentals/async now needs sqlalchemy-cubrid>=1.5 (1.4.x allows SQLAlchemy 2.1, where its async adapter calls the removed await_ attribute; 1.5.0 is the first passing release), and fundamentals/lob-handling is documented as needing pycubrid>=1.7 (1.6.x returns CLOB values with escaped newlines).
• Startup smoke test for the root FastAPI template app (#243) — templates/api-service-fastapi/tests/test_root_app.py imports the real app.main, runs its lifespan and checks /health through FastAPI's TestClient, using a throwaway SQLite DATABASE_URL so it needs no CUBRID. Previously CI only byte-compiled app/, so an import error or a missing dependency such as pydantic-settings (declared in the template's requirements.txt but absent from the shared smoke install list) could ship. Both the required pytest-suites lane in ci.yml (selected by any templates/api-service-fastapi/* change) and the non-PR smoke-test.yml suites now install the template's own requirements.txt and run this suite in its own process. tests/test_ci_scope.py covers the lane selection and workflow wiring. SQLite does not exercise CUBRID-specific SQL; the recipe suites continue to do that.
• make deps and a time-limited, classified make verify (#235, #236) — make deps installs pytest, sqlalchemy-cubrid[pycubrid] and the requirements.txt of every golden-backed example (a directory owning expected/) in one pip resolver call that honours PIP_CONSTRAINT; the discovery lives in the new scripts/example_requirements.py, which scripts/release_smoke.py install-examples now shares. It validates every path before printing any, and make deps fails (installing nothing) when a golden-backed requirements.txt path contains whitespace. make verify first checks that the selected examples' requirements are installed (failing once with "run make deps first"), then runs each script through the new portable, POSIX-only scripts/run_example.py (stdin from /dev/null, own process group; the whole group, including grandchildren, is killed on timeout, when the script exits and when the runner gets SIGINT, SIGTERM or SIGHUP; exit 124 plus a run_example: timed out after line on timeout; no GNU timeout; on a non-POSIX system it exits with "run_example.py requires POSIX process groups") under VERIFY_TIMEOUT seconds (default 60; the slowest golden took 7.2 s on CUBRID 11.4). Results are classified as ✓ PASS, ✗ MISMATCH (diff), ✗ EXEC-ERROR (exit status and last 20 lines; 128 + N for a script killed by signal N), ⏱ TIMEOUT (last 20 lines; only when exit 124 comes with the runner's timeout line, so a script that itself exits 124 is an EXEC-ERROR), ✗ NORMALIZE-ERROR, ✗ READ-ERROR or ? SKIP; the summary keeps N passed, N failed, N skipped and adds a count per failure class, and under GitHub Actions each failure emits an ::error file=...:: annotation. GETTING_STARTED.md, docs/quickstart.md and docs/ko/getting-started.md now install sqlalchemy-cubrid[pycubrid] in section 2, list the ai-agent template, and verify a checkout with a Python 3.11+ venv → make up → make deps → make verify; CONTRIBUTING documents both targets. tests/test_make_commands.py covers the make deps file list (pip replaced by a recorder) and its whitespace failure, the timeout and each failure class, a script exiting 124, a script killed by SIGTERM (exit 143), /dev/null stdin, and that no script or grandchild outlives a timeout, a normal exit, or SIGTERM/SIGHUP to the runner.
• Selectable local CUBRID version (#169) — CUBRID_VERSION=11.4 make up selects the root Compose image while retaining the 11.2 default and the existing bounded readiness helper. Version-switch instructions no longer require editing YAML, a fixed sleep, or automatic volume deletion; image selection is not a database-format upgrade.
• Advisory lane against pycubrid and sqlalchemy-cubrid main (#239) — the new .github/workflows/driver-main.yml installs both drivers from their main branches (pinned to the commits resolved at the start of the run; direct_url.json is checked after install) together with the requirements of 15 representative golden directories, then runs make verify on them against live CUBRID 11.4 on Python 3.12, so a driver regression shows up before it is released instead of after. It is advisory only: the recipe job has continue-on-error, no pull request runs it, and CI Gate does not depend on it. A failure opens or updates one tracking issue (ci: cookbook recipes failing against driver main, label ci), which is closed automatically when the recipes pass again — the reporting pattern of sqlalchemy-cubrid's upstream canary. No new schedule: the existing weekly ci.yml schedule calls it (job driver-main-advisory), skipped when neither driver's main changed in the last 8 days, and it can be dispatched manually. It runs only in the upstream repository. tests/test_ci_scope.py fails if the lane joins the gate, gains its own schedule or a pull-request trigger, loses continue-on-error, or stops installing the drivers from their main commits.
• Representative Python compatibility matrix (#130) — required PR/main CI checks Python 3.11–3.14 on CUBRID 11.4 using the existing read-only pycubrid connection and SQLAlchemy engine/session goldens, plus imports and source compilation. This small matrix does not duplicate the full Python 3.12 smoke/framework suite, and failure, cancellation or unexpected skip blocks the CI gate.
• Offline contributor command — make check combines lint, documentation, normalizer, golden-coverage, and isolated offline regression suites; make test-offline runs the suites without a database. CI uses the same command, and both live smoke jobs run the Make/readiness guards before driver selection.
• AI agent template (#111) — templates/ai-agent/ with 5 examples: agent state management (sessions, messages, tool calls with JSON columns), MCP tool chain (programmatic server invocation), RAG metadata hybrid (document store with SET tagging + SEQUENCE chunk tracking), agent loop (query → think → act → observe), and AI chatbot backend (SQLAlchemy ORM with JSON LLM I/O). Requires cubrid-mcp-server>=0.3.
• One-command dashboard demo — templates/dashboard/ now ships its own docker-compose.yml (CUBRID 11.4 + Streamlit at http://localhost:8501), and the five recipes read DATABASE_URL from the environment (default unchanged: cubrid+pycubrid://dba@localhost:33000/testdb) so the compose service can point them at the co-located container.
• Streamlit dashboard pytest suite (#103) — templates/dashboard/tests/test_dashboard.py uses streamlit.testing.v1.AppTest to exercise all 5 dashboard recipes: a parametrized smoke test that every recipe runs without raising, plus assertions that the seeded table viewer renders rows, the KPI page's four metric cards are non-empty, and narrowing the category filter shrinks the rendered dataframe. The suite runs against a live CUBRID instance when CUBRID_TEST_URL is set and otherwise falls back to a shared SQLite file for local/offline runs; conftest.py makes the recipes' CUBRID/MySQL-style AUTO_INCREMENT DDL SQLite-compatible via a dialect-gated SQLAlchemy event hook, without changing the recipes themselves, and drops the demo tables in FK-safe order before and after the session. SUPPORT_MATRIX.md's "Streamlit templates" row moves from "manual run" to this pytest suite. This replaces the unwired, CWD-relative tests/test_dashboard.py added by #120.
• Gate the Streamlit dashboard pytest suite in CI (#142) — Every pull request runs templates/dashboard/tests in its own required live-CUBRID 11.4 job, separate from the Flask/FastAPI database. On pushes to main, nightly, and manual smoke runs, each existing 11.2/11.4 matrix job first finishes the Flask/FastAPI suites, then stops their container and runs the dashboard suite in a separate disposable CUBRID container of the same version. This removes the shared-schema FK failure (cookbook_sales references cookbook_products) without deleting another recipe's tables or relying on suite order. The dashboard's own fixture still drops its tables in FK-safe order, and its SQLite-only AUTO_INCREMENT hook is scoped to its test URL and removed even when teardown fails. SUPPORT_MATRIX.md and docs/index.md describe the trigger-specific coverage and isolation.
• Live async-worker database task checks (#129) — templates/async-worker/tests invokes the existing sales aggregation, report, and batch email tasks directly without Redis, then confirms CUBRID persisted their job states, JSON results, reports, and email logs. The suite requires an empty dedicated database, fails on a configured connection error or preexisting worker tables, and removes only its own tables. A separate required CUBRID 11.4 PR job and the non-PR 11.2/11.4 smoke matrix gate this database path; broker delivery and Celery's result backend remain manual coverage.
• Live Django SQLAlchemy-bridge checks (#128) — templates/django/tests exercises the existing Django HTTP /health and /items views against CUBRID, then updates and deletes the persisted row through the template's SQLAlchemy bridge. It does not add a native Django CUBRID backend, ORM model, or migration. The suite rejects non-CUBRID or unreachable configured URLs and preexisting cookbook_items, cleans up only its own table, and runs in a separate required CUBRID 11.4 PR job plus the non-PR 11.2/11.4 smoke matrix after colliding examples.
• CUBRID-distinctive SQL feature recipes (6 new pycubrid scripts):
  • fundamentals/pycubrid/17_window_functions.py — ROW_NUMBER/RANK/DENSE_RANK, LAG, running SUM over partitions (with deterministic tie-breakers)
  • fundamentals/pycubrid/18_recursive_cte.py — WITH RECURSIVE number series and hierarchy path building (contrast with 08 CONNECT BY)
  • fundamentals/pycubrid/19_pagination.py — LIMIT/OFFSET vs CUBRID-idiomatic FOR ORDERBY_NUM() BETWEEN, plus the ROWNUM caveat
  • fundamentals/pycubrid/20_timezone_datetime.py — DATETIMETZ/DATETIMELTZ native reads and SET TIME ZONE; TIMESTAMPTZ rendered via server-side TO_CHAR to sidestep pycubrid#289
  • fundamentals/pycubrid/21_enum_type.py — ENUM declaration-order sorting, col + 0 ordinal, out-of-set rejection
  • fundamentals/pycubrid/22_date_formatting.py — TO_CHAR/TO_DATE date and number formatting with visible fixed-width padding
• v1.6.x feature recipes (8 new scripts):
  • fundamentals/async/ — pycubrid.aio + SQLAlchemy async engine

... (truncated)

Commits

• 50e5d34 docs: keep Python Cookbook contribution rules inside the repository (#563)
• e7856da docs: remove deprecated organization roadmap and project board references (#560)
• d47de69 docs: clarify local issue and PR evidence ownership (#557)
• 7997b47 fix(ci): restore required Korean README translation synchronization (#556)
• df8ec20 docs: make Korean README translation drift advisory after finals (#555)
• 1ac2b8f docs(fundamentals): fix the pandas setup directory (#543)
• 3be9fbf chore(deps): bump astral-sh/setup-uv from 10.3.2 to 10.3.3 in the github-acti...
• 20eca18 chore(deps): bump pymdown-extensions in /.github (#546)
• 652c0f9 chore(deps): bump mkdocs-material in /.github (#545)
• 456570a chore(deps): bump fastapi in /templates/api-service-fastapi/recipes (#549)
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[yeongseon]

The release smoke-test workflow pin advances to a later commit, but the reusable workflow's content blob is identical at both revisions. This is a low-risk pin refresh; current-head CI and security checks passed. Approved.