Debug Run Navigation

[warrensplayer]

Current behavior

On the Debug page, the user is only allowed to see the most recent "relevant" run that is determined when querying for runs based on the Git commit shas of that user's local environment. There are use cases where a user would wish to select from other runs.

See "Problem Statement" from ClickUp for further details: https://app.clickup.com/18033298/docs/h6amj-41627/h6amj-36067

Desired behavior

Allow a user to switch between all "relevant runs".

New run navigation component

ClickUp requirements: https://app.clickup.com/18033298/docs/h6amj-41627/h6amj-36087

Technical Requirements

• Refactor/replace DebugRelevantRunBar with new navigation component
  • If there is only one relevant run, the Debug page will be showing that and this component will be hidden
  • Component is made up of
    • Header
      • Shows information about the most recent relevant run.
      • Will have a prominent CTA button which says "Switch to latest run"
      • CTA will be enabled if page is not showing the most recent run. Clicking it will move the page to the most recent run
      • Will show "You are on the most recent run" if the page is showing the most recent run and CTA will be removed
      • Will show a caret on the left to indicate it is expandable if
        • there are any relevant runs older than current
        • more than 1 relevant run more recent than current
      • UI Concerns
        • Hide commit message and spec counts and smaller breakpoints

Example Header States

Most recent run is running and component is not expandable because there is only one more recent run than selected

Most recent run is running and component is expandable because there is more than one run that can be switched to

Most recent run is the one currently shown on the page

Most recent run is completed and is not currently selected

* Commit list
  * Show list of commits that contain relevant runs returned after querying Cypress Cloud
  * Include the current commit of the user's environment even if it does not have any runs
  * Will be in descending order by run number
  * Will show a message at the bottom if more than 100 runs are found that allows a user to follow a link to the project in Cypress Cloud
  * UI Concerns
    * Should have a max-height of 50%-70% of viewport height and scroll content if it is larger than that

Complete commit list showing commits with runs

Message shown at bottom of the expanded component if more than 100 runs are found

* Commit
  * Show commit sha and commit message
  * Will have a "Checked out" badge if the commit is the currently checked out commit
  * Runs associated with the commits will be nested underneath
  * UI Concerns
    * Truncate commit message at smaller breakpoints

Commit row showing the "Checked out" badge

* Runs
  * Show run status component, test counts component, spec counts, and duration/createdAt component
  * Will have a grey background and a checkmark shown if it is the run currently selected by the page
  * Runs that are not the currently selected run should be able to be selected
    * Will show the same grey background on hover for all runs that are not the current selected run (see Figma [prototype](https://www.figma.com/proto/ooXxp2usVdriapxZsFXFhn/In-App-Test-Results-View?page-id=1151%3A122273&node-id=1892%3A178911&viewport=-8026%2C2502%2C0.25&scaling=min-zoom&starting-point-node-id=1892%3A178911&show-proto-sidebar=1))	
    * Should show appropriate cursor to indicate it can be selected
    * Should be keyboard navigable
    * Selecting a row via clicking or with the keyboard should close the expanded component and move the Debug page to show the selected run
    * UI Concerns
      * Hide spec counts and duration/completedAt information at smaller breakpoints

Shows a selected and non selected run

Polling Updates

Currently, there are two pollers that help control the features of the Debug page:

• RelevantRunsDataSource controls the call to runsByCommitSha to determine the CloudRuns that are determined to be most "relevant" to the list of local commit shas. It polls every 30 seconds to determine which runs are considered current and next
• RelevantRunSpecsDataSource controls the call to runsByNumber for running runs. When a running run is found and being shown on the Debug page, it will poll every 15 seconds to return the updated information for the running run

Updates
The new Run Navigation component will now display up to 100 additional runs to pick from instead of just current and next. The following updates will be needed to support this functionality

• RelevantRunsDataSource should now calculate are return

  • current - this remain the same and be the run used by the sidebar badge as well as the Debug page for showing the contents on the main part of the page.
  • latest - this should replace next and will be the run used by the Run Navigation in the header part of the component. If latest is the same as current, then that is when the 'You are on the latest run' state for the header should be used
  • all - this will represent all relevant runs calculated for the given commit shas (including current and latest above). The logic should go throw the returned runs and stop when it finds a commit sha that has at least one "completed" run (status of run is not RUNNING). It should still return all runs for that furthest back commit that meets that criteria [See "What is shown for relevant commits" in the Clickup requirements here for more detail]

• RelevantRunSpecsDataSource will now possibly need to watch more than 1 running run

  • The initial implementation would always poll for both current and next, regardless of which run was running. In the issue for showing the details of a running run on the Debug page, this datasource is being updated to have a runNumber as a parameter so that it only polls for the running run. This will need to be updated to allow for an array of run numbers to poll for that represents all the running runs. The GQL query in this datasource will need to be generated dynamically to create an alias for each run number that should be polled. Additional fields will need to be added to support the additional data being shown in the new component (test counts, duration, createdAt)

Relevant run switching and persistence
The RelevantRunsDataSource caches the current run that is shown on the Debug page. The logic for this cache should mostly stay as it is currently set, except for one scenario:

• When determining if the cached current run should change, the logic should consider the commit sha. If a completed run is found that is newer than the current run, only update the cached run if the newer run is for a newer(i.e. different) commit. This will allow a user to remain on an older run within the most recent commit if it was being viewed.

[See "Relevant run switching and persistence" in the Clickup requirements here for more detail]

References

ClickUp - https://app.clickup.com/t/18033298/PM-2859
Figma - https://www.figma.com/file/ooXxp2usVdriapxZsFXFhn/In-App-Test-Results-View?node-id=1151%3A122273&t=ngBnD28gqvAenHrq-1
Figma prototype - [Showing some interactions] https://www.figma.com/proto/ooXxp2usVdriapxZsFXFhn/In-App-Test-Results-View?page-id=1151%3A122273&node-id=1892%3A178911&viewport=-8026%2C2502%2C0.25&scaling=min-zoom&starting-point-node-id=1892%3A178911&show-proto-sidebar=1

[warrensplayer]

Hey team! Please add your planning poker estimate with Zenhub @astone123 @lmiller1990 @marktnoonan @mike-plummer @ZachJW34

[warrensplayer]

Would like to discuss with the team if we should break this one up. At least maybe between front end and back end.

[lmiller1990]

I have no problem reviewing a big PR, anything more than 3-4 days of work probably needs to be split up for the purpose of paralellization, though.

Either way, the number of tickets shouldn't change our overall estimate, we can figure out the actual ticket/work split prior to the sprint starting.

[lmiller1990]

I'd like to pick up the server aspect of this. It'll also help drive the "better App <> Cloud" testing iniaitive.

[lmiller1990]

I will start working on "Polling Updates". Before coding too much, I'm going to come up with a bit of strategy.

Right now this page uses runByNumber - this only fetches a single run. We need to get a list of these - we could use CloudProject.runs(last: 100) for example, to get the last N runs, which gets them all in 1 request.

Then when you click one, we can get more details with runByNumber($number). I think that's the intention here.

Got another question:

CloudRunStatus is either

CANCELLED
ERRORED
FAILED
NOTESTS
OVERLIMIT
PASSED
RUNNING
TIMEDOUT

The requirement is:

all - this will represent all relevant runs calculated for the given commit shas (including current and latest above). The logic should go throw the returned runs and stop when it finds a commit sha that has at least one "completed" run. It should still return all runs for that furthest back commit that meets that criteria [See "What is shown for relevant commits" in the Clickup requirements here for more detail]

What constitutes "completed"? It's not entirely clear and this term does not seem to be mentioned in ClickUp.

[warrensplayer]

What constitutes "completed"? It's not entirely clear and this term does not seem to be mentioned in ClickUp.

I added a clarification to that section you quoted to indicate that a completed run is any that does not have a status of RUNNING. It is also defined in the Problem Statement part of the ClickUp here.

[warrensplayer]

Right now this page uses runByNumber - this only fetches a single run. We need to get a list of these - we could use CloudProject.runs(last: 100) for example, to get the last N runs, which gets them all in 1 request.

I think there are a couple of ways to approach this. The one main thing to keep in mind between the different Cloud GQL fields is that the CloudProject.runs(last:100) returns the 100 most recent runs for the project. On the Debug page, it is only concerned with runs associated with the last 100 commits on the current local Git branch.

[lmiller1990]

@warrensplayer I initially thought we needed a runsByNumber (we've only got runByNumber, returning a single run) but now I think we can just use runsByShas and figure out the correct number to poll based on that. I'll move forward with this approach for now.

I'm going to start by ensuring we fetch and derive the correct run data for the new UI, then move onto updating the polling logic.

I have split the UI work into a separate ticket, that's here: #26018

[cypress-bot]

Released in 12.9.0.

This comment thread has been locked. If you are still experiencing this issue after upgrading to
Cypress v12.9.0, please open a new issue.