Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SPLIT_TIME_THRESHOLD is not respected when using SPLIT_OUTPUT_FILE #284

Open
parkuman opened this issue May 10, 2024 · 0 comments
Open

SPLIT_TIME_THRESHOLD is not respected when using SPLIT_OUTPUT_FILE #284

parkuman opened this issue May 10, 2024 · 0 comments

Comments

@parkuman
Copy link
Contributor

parkuman commented May 10, 2024

Wanted to open a discussion about the intended behaviour of SPLIT_TIME_THRESHOLD in conjunction with SPLIT_OUTPUT_FILE.

Context
In my CI setup, the original timings.json file is kept in cypress/e2e/<sub-project>/timings.json, and I am setting the SPLIT_TIME_THRESHOLD to be 0.2.

I am also using SPLIT_OUTPUT_FILE to save the updated timings for each parallel node into their own artifacts directory like so:
artifacts/<sub-project>/split-timings/node-<1,2,3,etc>/timings.json. These are then merged back together by a later merge job using the cypress-split-merge binary (which is working great btw!)

Expected Behaviour (in my head)
The behaviour I was expecting here was that the SPLIT_OUTPUT_FILE would not include updated timings unless the threshold is met. If the threshold was not met, it would either:

  1. not write out an updated timings.json at all (this might not work well when merging later)
  2. or it would write to the node-X output file, but it would be the original times of the test cases and not the updated ones. in this case, when merging the updated timings, Git can realise there is no change to the merged timings file and not bother committing.

Actual Behaviour
Despite the changes not meeting the threshold, it writes the updated timings to the SPLIT_OUTPUT_FILE anyway:
image

I can see in the code it's because OUTPUT !== the INPUT file, so we write it anyway:

if (SPLIT_OUTPUT_FILE !== SPLIT_FILE) {

As a result of the above, later in our merge job the spec timings are being updated no matter what the threshold is.

Question for you
What would be the ideal way for SPLIT_OUTPUT_FILE to respect SPLIT_TIME_THRESHOLD? Would love to help hop on a solution!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant