Skip to content

Don't write status file during dry runs.

gitlab-qa-bot requested to merge github/fork/garybernhardt/dont_write_status_file_during_dry_runs into master

Created by: garybernhardt

Doing a dry run currently fills the status file with near-zero runtimes, replacing any that are there. This seems wrong, since those times don't represent the actual runtime of any test code.

In case that's not convincing, here's why I ran into this. (But if it's convincing, this is just boring yak detail.)

  • I'm writing a thing that gathers a list of all specs, then spawns multiple rspec processes, each with a subset.
  • I want to balance the runtimes of the parallel subprocesses as much as possible, preventing a single subprocess from ending up with all of the slow specs.
  • That requires looking at the status file to get the specs' runtimes.
  • But I also need to catch new specs that aren't yet in the status file, which means doing a dry-run before spawning the parallel processes.
  • The problem, then: doing a dry run to discover test names smashes the existing status, so I can't find out how long the tests take.
  • I could pull the statuses before doing the dry run, thus giving me both pieces of data. But if I'm doing a parallel run of only a subset of the tests, this will smash the statuses of any tests not in that run. But in practice, I mostly do single-file runs. Smashing other files' statuses means that the parallel runner often won't have runtimes for the specs it's running.

Welcome to my yak shave.

Merge request reports