seeding tools: write ui-test-only curriculum content files to custom location#70203
Conversation
Conflicts: dashboard/config/locales/scripts/en.yml
etaderhold
left a comment
There was a problem hiding this comment.
Thanks for including tests for the non-default root directory. This helps maintain confidence that moving this test content won't break the seeding-from-staging procedure (not that the UI test files have a strong need to be seeded to production anyway).
I see a bunch of ui-test content already exists and isn't being moved to the new directory as part of this PR. Is that going to cause any problems seeding or modifying that content? Maybe if one of these is edited on levelbuilder it would save a copy to the new folder or while keeping the old copy in the old place too? I'm not sure.
Good catch! The only one I see of these is . that one is depended on by allthemigratedthings.course, which is seeded in non-ui-test environments, so I've renamed that one to allthemigratedthings.json and kept it in dashboard/config. we stopped using this course in ui tests in #66462, so this is just to keep seeding working, without creating ourselves a land mine by removing the files from the repo without removing the objects from prod and other environments.The other files starting with |
Conflicts: dashboard/config/locales/courses/en.yml
…location (#70203) * customize write location of script_json directory for ui test scripts * also customize write location for ui test course files * customize course offering ui test file location * use levelbuilder controls to create new ui-test-artist course * make assessment_feedback_download.feature depend on ui-test-artist * actually seed new content in ui tests * fix display names * fix course offering content settings * publish ui-test-artist course * save misc updates to ui-test-artist script json * rename ui-test-versioned-script course offering to allthemigratedthings
…0502) * Re Restore "seeding tools: write ui-test-only curriculum content … (#70203)" This reverts commit 36ac2f4. * temporarily generate cached staging build to temp location * Revert "temporarily generate cached staging build to temp location" This reverts commit 8a71330. * run drone against temp cached build files * temporarily skip removing records when seeding course offerings * Revert "temporarily skip removing records when seeding course offerings" This reverts commit 329bc4c. * improve error message when preventing course version change * preserve ui-test- prefixed offerings during CourseOffering.seed_all UI test course offerings are now stored in a separate directory (test/ui/config/course_offerings/) and seeded separately. This change prevents seed_all from destroying them when it runs against the regular config/course_offerings/ directory. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com> * Revert "run drone against temp cached build files" This reverts commit efb732d. * rerun drone --------- Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
In the process of creating some new ui test scripts which are not needed in production, I noticed that we have logic to seed from the custom config location
dashboard/test/ui/config/, but not to write to that location. This PR updates the write logic for levelbuilder + cloning pathways to start writing to the following directories when appropriate:Testing story
ui-test-clone_migrated_unitpath are all writing files to the new location:ui-test-artistcourse via http://localhost-studio.code.org:3000/courses/new`Unit.find_by_name('artist').clone_migrated_unit('ui-test-artist', destination_unit_group_name: 'ui-test-artist')http://localhost-studio.code.org:3000/course_offerings/ui-test-artist/editdashboard/test/ui/configFollow-up work
dashboard/test/ui/configalready have names starting with theui-test-prefix, I'm using this name prefix as a heuristic for when to write to this custom location. In the future, if we find that we want to move scripts like allthethings here without changing its name, we could consider using a customui_test_onlyfield on each object. TBD whether we want to allow this, or if we prefer to require that ui-test-only objects have theui-test-prefix, so I'm erring on the side of being more restrictive for now.UI_TEST_SCRIPTS, since this PR removes the last UI test that depended on it. the verification steps for this are a little too involved for me to want to tack them onto this PR. see Prefer test units in UI tests #66876 for an explanation.