[patil2001]

Summary

The CrewAI library recipe mounts ./data/crewai at /app, but the pinned image (tham0nk/crewai-studio@sha256:5438b8fb…) never uses /app. The image config has WorkingDir: /CrewAI-Studio and the command streamlit run ./app/app.py. Its app/db_utils.py opens DB_NAME = 'crewai.db' relative to that directory. I read this from the pinned image's application layer.

User impact: every agent, task, crew and tool definition is written to /CrewAI-Studio/crewai.db in the container's writable layer. All of it is lost whenever the container is recreated, which happens on ods update, on disable and enable, and on any compose change. The data/crewai folder stays empty.

Fix

Set the recipe command to link crewai.db to /app/crewai.db and then exec the image's original Streamlit command. The working directory stays /CrewAI-Studio, so the app's relative img/ and .streamlit/ assets still load. ln -sf is idempotent across restarts. The README says where the data now lives and that a database from an earlier container is not carried over.

This is the focused rebase onto main that #4960 was asked for. #4960 was closed only because its public-beta target was retired. This version is smaller: it runs one sh -c line and does not include the migration procedure.

AI Assistance

AI-assisted (Claude Code). The author reviewed the change and the pinned image's config and db_utils.py.

Release Lane

• Mainline change targeting main

Changed Surface

• ods/extensions/library/services/crewai/compose.yaml: adds command
• ods/extensions/library/services/crewai/README.md: Data note
• ods/tests/test_crewai_persistence.py: new script test, registered in ods/tests/ci-suite.txt

Validation

• python3 tests/test_crewai_persistence.py (Ubuntu 24.04): fails on upstream/main ("the image command leaves crewai.db in the container layer") and passes with the fix. The test runs the recipe's real shell command twice, to cover a restart, in a temporary working directory. The /app mount is redirected to a temporary data folder, and a stand-in streamlit opens crewai.db the way db_utils.py does. The test then checks that both writes landed in the data mount.
• python .github/scripts/list-unwired-tests.py --check: PASS
• git diff --check upstream/main...HEAD: clean

🤖 Generated with Claude Code

[patil2001]

CI note: frontend (windows-latest) fails in src/pages/PixelArtifacts.test.jsx ("binds explicit download prose to verified bytes...", expected [ <a> ] to have a length of +0 but got 1). This PR only touches the CrewAI library extension and its pytest, not the dashboard. The same test fails identically on main at 9ba6f6d (#7911), job https://github.com/Osmantic/ODS/actions/jobs/119447820094, so it is a pre-existing main failure, not caused by this change.

[Lightheartdevs]

Thanks for fixing CrewAI's database persistence with a focused recipe change and clearly documenting the existing-data limitation.

Advisory status: looks merge-ready

What looks good:

• The pinned image's configuration uses /CrewAI-Studio and the existing Streamlit command. Its application layer opens DB_NAME = 'crewai.db' relative to that directory. Linking that file into the existing /app data mount addresses the actual write path while preserving the working directory and startup command.
• The regression test executes the recipe's shell command twice and verifies both SQLite writes in the data mount; it is registered in ods/tests/ci-suite.txt.
• The README explicitly says older container-local databases are not migrated by this change.

What I checked:

• Exact head 3f8e4f98a3; diff, surrounding recipe, discussion, CI wiring, and pinned image configuration/application-layer bytes. All 73 current checks passed; the earlier Windows failure mentioned in discussion is no longer present in this check rollup.
• Local WSL: python3 ods/tests/test_crewai_persistence.py — 2 passed.
• These tests use a stand-in Streamlit process; I did not run a live CrewAI UI/recreation journey.