CC-39280 Map the Robot UI retirement and gate new Robot tests - #1096
Draft
stereomon wants to merge 114 commits into
Draft
Conversation
Writes the ticket key into all 105 rows of the robot-ui-to-cypress matrix, so the lane has one owner and a second run cannot pick up rows that are already held. Nothing but the claim, ahead of any authoring. The matrix these rows live in is this ticket's first acceptance criterion.
Points the row at cypress/e2e/yves/cms/cms-page-publish.cy.ts and names the test, so the scanner proves a named test rather than a file. The classifier proposed a backoffice path; the assertion is on the storefront, so it lands under yves like the other storefront-asserting cms spec. Status reads AUTHORED, not ported -- there is no verified run yet.
The focused Cypress lane ran the new spec in shard 5/5 and it passed: one test, one passing, nothing pending or skipped. The row moves to TARGET_GREEN and left-to-port drops to 89. The source stays active. It is deleted once the cypress-tests pull request is merged, not before.
Test titles moved to the repository's subject-and-should convention, and the spec now asserts the content block too. The recorded run verified the earlier title-only test, so it no longer proves anything and is cleared -- the row is back to AUTHORED until a fresh run lands.
stereomon
force-pushed
the
feature/cc-39844-migration-matrices
branch
from
August 21, 2026 17:17
a36e3ed to
1270425
Compare
…273/cc-39280-sunset-robot-framework-coverage-map-one-clean-cutover
stereomon
force-pushed
the
feature/cc-39273/cc-39280-sunset-robot-framework-coverage-map-one-clean-cutover
branch
from
August 21, 2026 17:18
9ab2833 to
f9dfa95
Compare
The Cypress replacement for Content_Management passed in a named run: shard 3/5 of the focused dispatch, spec 17 of 22, one test, zero failures. Verified from the shard log rather than the run conclusion, because a focused Cypress run can be green while the spec never executed.
The delta landed as two tests inside the existing ACL spec rather than one combined test, so the recorded target names the deny test and the rationale names both. The row stays AUTHORED until a run covers it.
Both delta tests passed in a named run: shard 3/5, spec 1 of 22, four tests passing and none failing. The verdict came from the job's full log fetched through the jobs API. The gh run view --log output for the same job stopped mid-checkout at 201 lines, which reads as "the spec never ran" if taken at face value.
Each one regenerates the API specification mid-test by running a Zed console command, twice or three times. cypress-tests registers a single task that checks whether a file exists, and in CI the Cypress runner has no route into the application container, so there is nothing there to run a console command with. Neither can become an honest Cypress test until that gap is filled, so they are recorded as blocked rather than counted as work still to do. The configuration scenario also asserts through REST, which belongs in a Glue suite.
New_Customer_Registration asserts a flash string that the existing storefront registration test already asserts verbatim, and that test was passing in the run recorded on the user-control row. Email_Confirmation asserts that an unconfirmed customer cannot log in. Suite does not behave that way: double opt-in defaults to off and suite adds no override, so registration is followed by a successful login, which its Cypress sibling proves in the same run. The gate is covered by the customer facade test, whose data provider mocks the config both ways and includes the unconfirmed-login case, so there is nothing a browser test could add without flipping a config the environment never flips.
Both tests passed in a named run: shard 1/5, spec 6 of 23, two passing and none failing. The crawl itself took 80 seconds, and it asserts the link list is non-empty, so it cannot have gone green having visited nothing.
I parked these claiming a console command could not be run mid-test. That is false. cy.runCliCommands posts cli-command operations to the dynamic-fixtures endpoint, which executes them inside the application container, and it is already how cy.runQueueWorker drains the queue. The mistake came from reading only the task registrations in cypress.config.ts and concluding the runner had no route into the container, without checking the custom commands. Both rows go back to portable, and downloading the specification is covered too: the isFileExists task and cy.readFile handle the file.
The back-office profile edit reaches the storefront: six passing, none failing, including the new round trip at twelve seconds. The address scenario's own tests passed in the same run, but its row stays authored until the account-page fix is verified, because the navigation crawl in the sibling spec failed and that verdict covers the whole batch.
…uthored User_Account is green: eight passing in the overview spec including the wishlist and returns pages, and four in the address spec including deletion and the back-office round trip. Glossary is authored, back-office half only, with the reason the storefront half is left out recorded on the row.
It deactivates the Invoice payment method globally to prove it disappears from checkout. That method is depended on by the checkout, order-amendment and recurring-order specs, the shards run concurrently against one application, and packing is nondeterministic, so whichever of those lands alongside would fail. A fixture-created payment method is not a way round it: nothing renders it in checkout without a storefront plugin behind it. Unblocking needs a serial lane or per-test payment-method state, which is recorded on the row.
Its target path moves to customer-impersonation.cy.ts. The row needed new storefront impersonation support, and the same support is what unblocks both company rows, where the company user is created through a form and nothing knows its password.
…ossary Both agent-assist and split-delivery passed in a named run, four tests and one test respectively, none failing. Glossary loses its verified run. It was recorded on a genuine pass, but a later run showed the edit test failing twice on retry, so it was never reliably green. The row goes back to authored until the fixed lookup is proven.
The b2c and b2c-mp variants have no order-building dynamic-fixture helper, so only suite can drive the fixture order through the picking subprocess.
The parallel_ui static_demodata_set copy of Fulfillment_app_e2e is the same journey as the ui/b2c one this batch ports: same warehouse-user checkbox, same BAPI warehouse assignment, same Glue order, same back-office OMS walk to ready for picking, same variants — only the SKUs differ. It was still RESHAPE with its own unwritten target spec, so the platform batch would have re-covered both of the it()s delivered here, with none of the warehouse context. Marking it OBSOLETE and pointing covered_by at the ported row follows what the sibling Click_and_collect entry in that same Robot file already does. The port walks Pay and Skip timeout through the UI where the ui/b2c source updated the database directly, so it covers this variant's browser half in full.
Every MIGRATE row of the order domain now carries a target test name and a local run.
The spec now opens its order by reference, so the row carries the run that proved that shape rather than the earlier one.
…oven Product_PDP now carries target_test and a local run, so it flips to TARGET_GREEN. The run is a real suite-repository Cypress run against the docker/sdk stack, which is why it is written as a `local …` value rather than a CI URL.
Customer_Specific_Prices now carries target_test and a local run, so it flips to TARGET_GREEN. Two of eighteen product MIGRATE rows are proven.
…ing as done Product_Original_Price now carries target_test and a local run, so it flips to TARGET_GREEN. Three of eighteen product MIGRATE rows are proven. Merchant_Product_Original_Price pointed its target_path at the yves spec this batch just created, with no target_test, so it scanned PRESENT the moment the file landed. Its journey is authored in the Merchant Portal, so that path was wrong regardless. Cleared the path only — the verdict stays MIGRATE and the row stays unclaimed for the merchant batch to decide.
…ally proven Discontinued_Alternative_Products now carries target_test and a local run, so it flips to TARGET_GREEN. Four of eighteen product MIGRATE rows are proven.
Catalog_Actions now carries target_test and a local run, so it flips to TARGET_GREEN. Five of eighteen product MIGRATE rows are proven.
Volume_Prices now carries target_test and a local run, so it flips to TARGET_GREEN. Six of eighteen product MIGRATE rows are proven.
Measurement_Units now carries target_test and a local run, so it flips to TARGET_GREEN. Seven of eighteen product MIGRATE rows are proven.
Packaging_Units now carries target_test and a local run, so it flips to TARGET_GREEN. Eight of eighteen product MIGRATE rows are proven.
Product_Bundles now carries target_test and a local run, so it flips to TARGET_GREEN. Nine of eighteen product MIGRATE rows are proven.
Catalog now carries target_test and a local run, so it flips to TARGET_GREEN. Ten of eighteen product MIGRATE rows are proven.
Back_in_Stock_Notification now carries target_test and a local run, so it flips to TARGET_GREEN. Eleven of eighteen product MIGRATE rows are proven.
Configurable_Product_Checkout now carries target_test and a local run, so it flips to TARGET_GREEN. Twelve of eighteen product MIGRATE rows are proven.
Configurable_Product_PDP_Wishlist_Availability now carries target_test and a local run, so it flips to TARGET_GREEN. Thirteen of eighteen product MIGRATE rows are proven.
…y proven Configurable_Product_PDP_Shopping_List now carries target_test and a local run, so it flips to TARGET_GREEN. Fourteen of eighteen product MIGRATE rows are proven.
…cally proven Configurable_Product_RfQ_OMS now carries target_test and a local run, so it flips to TARGET_GREEN. Fifteen of eighteen product MIGRATE rows are proven.
Manage_Product now carries target_test and a local run, so it flips to TARGET_GREEN. Sixteen of eighteen product MIGRATE rows are proven.
Product_Restrictions now carries target_test and a local run, so it flips to TARGET_GREEN. Seventeen of eighteen product MIGRATE rows are proven; only Product_Availability_Calculation is outstanding.
Product_Availability_Calculation now carries target_test and a local run, so it flips to TARGET_GREEN. All eighteen product MIGRATE rows are proven.
All twenty-one product rows now carry pr_target, so the rendered checklist names the pull request the ports land through.
pr_target says where a row's target landed. An OBSOLETE row has no target, so pointing it at the batch PR claims something the PR does not contain; every other batch leaves it unset on its obsolete rows. Also carries the retitled shopping-list target_test and the re-proven Manage_Product run.
…t their new runs The multistore product and product offer specs were reshaped so a retry has a precondition left to stand on, which makes the 41s and 44s runs the rows were carrying evidence for code that is no longer on the branch. Both rows now cite the runs of the specs as they stand, 43s each. Re-scanned before rebuilding: the rework renamed a wait helper but no test, so every recorded target_test still resolves and scan.jsonl came back byte-identical.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Settles the Robot UI retirement map — the coverage map this ticket asks for before anything is deleted.
CC-39280
cypress-testsmaster rather than the matrix branch, which the classifier had read 41 specs stale.decided_by: human: 90 in scope (87MIGRATE, 3RESHAPE) and 15 needing no port. No unresolved verdict.contentdomain's target recorded.No Robot test or resource file is touched — Robot is being retired, not maintained. The lane is removed from suite CI in suite#1087 instead.
Rationale, per-row reasoning and the parked decisions are in the Jira ticket.
Test plan
gate.pyprintsgates clean;build.py --checkandrender.py --checkconfirm the committed output is not stale.Checklist
See
test-inventory/migrations/by-domain/robot-ui-to-cypress/for all twelve domains, andPROGRESS.mdfor the rollup.