[Product Launch] Rerun Failed Tests (circleci tests run)

@drilon241 if you send over your config.yml to sebastian @ circleci.com I can take a look at well. Were you following the cypress instructions in the docs Re-run failed tests only (preview) - CircleCI?

If you’d be wiling to share it, @villelahdenvuo, can you paste the command you’re using with the circleci tests run tool? (obscure whatever path or project name information you’d like)

I think you could have the result you’re looking for (the list of values sent to the -spec flag comma separated) by using the tr translate tool, like so:

$ echo "arg1 arg2 arg3" | tr ' ' ',' | xargs -I {} cypress run -spec {}

cypress run -spec arg1,arg2,arg3

Removing the initial echo command, and having the contents of the --command flag be --command="tr ' ' ',' | xargs -I {} cypress run -spec {}".

The tool currently expects input to the tool to be space or newline delimited, but how it’s assembled or arranged for the specific test runner you’re using is very flexible, depending on your comfort and familiarity with built-in bash tools.

1 Like

Config sent via email. Thanks for looking into this :pray:
I was following the official docs but maybe I missed something.

I just followed the example on the circleci docs for cypress and it worked.

Thanks, I’ll try your way. It currently works with the spaces, just gives a warning.

I personally don’t love the idea of cramming a complex piped command in a string parameter, though. It doesn’t seem very readable for humans.

This is a great feature. Is there any way to determine within the job that it was started via “Re-run failed tests only”? i.e. an environment variable?

1 Like

@bbrinck no official way at this time. We’ve had a couple of users leverage this workaround: Detect Rerun of a job

This is a huge feature for us! I implemented it according to Re-run failed tests only (preview) - CircleCI but it didn’t work. That page doesn’t mention closed beta. Is there a way to get into the beta?

There’s a small issue with the docs for Cypress

circleci tests glob "cypress/**/*.cy.js" | circleci tests run --command="xargs npx cypress run --reporter cypress-circleci-reporter --spec" --verbose --split-by=timings"

That closing " shouldn’t be there

Also, should the tests be comma separated as before for test splitting?

Good spot on the docs typo. Opened a PR to make that change, thank you.

The test files should be delimited by a space, that’s the default output of the circleci tests glob command. Is that what you’re asking?

If you email me your org name, I can add you to the closed beta in the next couple of business days. sebastian@circleci.com

Thanks @sebastian-lerner, emailed you.
If we don’t do comma separation for the tests we get the following warning

This will work, but it's not recommended.

If you are trying to pass multiple arguments, separate them with commas instead:
  cypress run --spec arg1,arg2,arg3

Should we just ignore this warning?

Email received, thank you.

We’ve been okay just ignoring the warnings from Cypress when we were doing internal testing. A user above has also mentioned that it works fine for them with ignoring the warnings.

I’ll look more deeply with my team to see if there’s anything we can do in the long-run to avoid that warning, but for now I think, it’ll be okay.

See this reply, with some bash magic it can be converted to comma separated list: [Product Launch] Re-run Failed Tests Only (circleci tests run) - #18 by chadchabot

Have you got any ideas brewing about how you’d use that information, @bbrinck?
If you can share those use cases, that could help inform how we’re building out the tool.

Our intention is that the workflow/job config should be pretty agnostic about whether an initial run or rerun with failed is happening.
That is, a rerun would have the same test runner and options used as the initial run, only with a subset of tests.

@villelahdenvuo that’s what we currently do but because new examples didn’t have it I was wondering if having commas is actually wrong as far as Circle is concerned.

Found two possible issues -

If you have parallelization enabled, every server will spin up even though you might have a single broken test.

If you trigger ‘rerun from failed’ on one test job it will trigger other test jobs with failed tests even if those jobs aren’t set up for it according to the docs.

@vlad for your first one, this is indeed expected behavior at this time as noted in the FAQs. We’re looking at ways to avoid spinning up additional VMs/containers, however for the vast majority of users we still see a substantial reduction in runtime & credits compared to rerunning all tests.

For the second item, can you send over an example workflow where you’re seeing this behavior? Are the other test jobs downstream in the workflow or run concurrently?

Apologies, didn’t see the FAQ. Yes, there’s definitely savings even with extra containers running. It’s just wasteful. If we have a long restore cache job and have a bunch of scaffolding then we spend a few minutes for nothing. Is there a way to detect what tests will run in the current instance? If there is then we can short-circuit the flow to exit if there are no tests.

About the second item, the jobs run concurrently, they are not downstream. They do have a common ancestor though. Here’s what it looks like. If I go to Cypress job, click ‘Rerun failed tests only’ then I expect it to only run the Cypress job but it also runs the playwright-e2e job.

In theory, I think yes. I don’t have any sample code yet on how to actually achieve that. You can probably write a step that is the first thing that executes that calls circleci tests run and instead of actually passing in the test runner to the --command to actually execute tests, you could echo or redirect that output to a file. And then check to see if that file is empty, don’t run any other steps.

Thanks for the workflow diagram, super helpful. We’re iterating on the behavior for this exact scenario actually. “Rerun failed tests only” is meant to be effectively equivalent to “Rerun workflow from failed”. So if there is a test failure in cypress-build, I would expect the failed tests from cypress-build to be re-run in the newly generated workflow. At the same time, playwright-e2e would also be re-run concurrently in the newly generated workflow, but if it’s not set up with circleci tests run, it should re-run all tests. The workflow would then proceed to downstream jobs if applicable. Concerns with that design?

It’s not urgent, but our primary use case is for code coverage. We save code coverage data when we run specs. If we run only a small subset of specs, that will save code coverage just for those specs, which messes up downstream tooling.

If there was, say, an environment variable that we could inspect, we’d just skip saving code coverage for these runs.

Right now, we’ve worked around this by adjusting our downstream tooling to notice code coverage data that is well below what we normally expect.

No issues at all except that ‘rerun from failed’ command is at the job level instead of workflow level which makes it confusing. If it was at the workflow level then rerunning all bad tests over all jobs makes sense. If I have to go to a job and click ‘rerun’ then it definitely seems like I’m just doing that for that one particular job.