DEV: Introduce automatic reruns to RSpec tests on Github actions (#24811)
What motivated this change?
Our builds on Github actions have been extremely flaky mostly due to system tests. This has led to a drop in confidence
in our test suite where our developers tend to assume that a failed job is due to a flaky system test. As a result, we
have had occurrences where changes that resulted in legitimate test failures are merged into the `main` branch because developers
assumed it was a flaky test.
What does this change do?
This change seeks to reduce the flakiness of our builds on Github Actions by automatically re-running RSpec tests once when
they fail. If a failed test passes subsequently in the re-run, we mark the test as flaky by logging it into a file on disk
which is then uploaded as an artifact of the Github workflow run. We understand that automatically re-runs will lead to
lower accuracy of our tests but we accept this as an acceptable trade-off since a fragile build has a much greater impact
on our developers' time. Internally, the Discourse development team will be running a service to fetch the flaky tests
which have been logged for internal monitoring.
How is the change implemented?
1. A `--retry-and-log-flaky-tests` CLI flag is added to the `bin/turbo_rspec` CLI which will then initialize `TurboTests::Runner`
with the `retry_and_log_flaky_tests` kwarg set to `true`.
2. When the `retry_and_log_flaky_tests` kwarg is set to `true` for `TurboTests::Runner`, we will register an additional
formatter `Flaky::FailuresLoggerFormatter` to the `TurboTests::Reporter` in the `TurboTests::Runner#run` method.
The `Flaky::FailuresLoggerFormatter` has a simple job of logging all failed examples to a file on disk when running all the
tests. The details of the failed example which are logged can be found in `TurboTests::Flaky::FailedExample.to_h`.
3. Once all the tests have been run once, we check the result for any failed examples and if there are, we read the file on
disk to fetch the `location_rerun_location` of the failed examples which is then used to run the tests in a new RSpec process.
In the rerun, we configure a `TurboTests::Flaky::FlakyDetectorFormatter` with RSpec which removes all failed examples from the log file on disk since those examples are not flaky tests. Note that if there are too many failed examples on the first run, we will deem the failures to likely not be due to flaky tests and not re-run the test failures. As of writing, the threshold of failed examples is set to 10. If there are more than 10 failed examples, we will not re-run the failures.
2023-12-12 18:18:27 -05:00
|
|
|
# frozen_string_literal: true
|
|
|
|
|
|
|
|
module TurboTests
|
|
|
|
module Flaky
|
|
|
|
class FailedExample
|
|
|
|
# @param [TurboTests::FakeExample] failed_example
|
|
|
|
def initialize(failed_example)
|
|
|
|
@failed_example = failed_example
|
|
|
|
@failed_example_notification = failed_example.notification
|
|
|
|
end
|
|
|
|
|
|
|
|
# See https://www.rubydoc.info/gems/rspec-core/RSpec%2FCore%2FNotifications%2FFailedExampleNotification:message_lines
|
|
|
|
def message_lines
|
|
|
|
lines = @failed_example_notification.message_lines.join("\n")
|
|
|
|
|
|
|
|
# Strip ANSI color codes from the message lines as we are likely running in a terminal where `RSpec.color` is enabled
|
|
|
|
lines.gsub!(/\e\[[0-9;]*m/, "")
|
|
|
|
lines.strip!
|
|
|
|
|
|
|
|
lines
|
|
|
|
end
|
|
|
|
|
|
|
|
# See https://www.rubydoc.info/gems/rspec-core/RSpec%2FCore%2FNotifications%2FFailedExampleNotification:description
|
|
|
|
def description
|
|
|
|
@failed_example_notification.description
|
|
|
|
end
|
|
|
|
|
|
|
|
# See https://www.rubydoc.info/gems/rspec-core/RSpec%2FCore%2FNotifications%2FFailedExampleNotification:formatted_backtrace
|
|
|
|
def backtrace
|
|
|
|
@failed_example_notification.formatted_backtrace
|
|
|
|
end
|
|
|
|
|
|
|
|
def location_rerun_argument
|
|
|
|
@failed_example.location_rerun_argument
|
|
|
|
end
|
|
|
|
|
2023-12-13 22:11:11 -05:00
|
|
|
def exception_name
|
|
|
|
@failed_example.execution_result.exception.class.name
|
|
|
|
end
|
|
|
|
|
|
|
|
def exception_message
|
|
|
|
@failed_example.execution_result.exception.message
|
|
|
|
end
|
|
|
|
|
DEV: Introduce automatic reruns to RSpec tests on Github actions (#24811)
What motivated this change?
Our builds on Github actions have been extremely flaky mostly due to system tests. This has led to a drop in confidence
in our test suite where our developers tend to assume that a failed job is due to a flaky system test. As a result, we
have had occurrences where changes that resulted in legitimate test failures are merged into the `main` branch because developers
assumed it was a flaky test.
What does this change do?
This change seeks to reduce the flakiness of our builds on Github Actions by automatically re-running RSpec tests once when
they fail. If a failed test passes subsequently in the re-run, we mark the test as flaky by logging it into a file on disk
which is then uploaded as an artifact of the Github workflow run. We understand that automatically re-runs will lead to
lower accuracy of our tests but we accept this as an acceptable trade-off since a fragile build has a much greater impact
on our developers' time. Internally, the Discourse development team will be running a service to fetch the flaky tests
which have been logged for internal monitoring.
How is the change implemented?
1. A `--retry-and-log-flaky-tests` CLI flag is added to the `bin/turbo_rspec` CLI which will then initialize `TurboTests::Runner`
with the `retry_and_log_flaky_tests` kwarg set to `true`.
2. When the `retry_and_log_flaky_tests` kwarg is set to `true` for `TurboTests::Runner`, we will register an additional
formatter `Flaky::FailuresLoggerFormatter` to the `TurboTests::Reporter` in the `TurboTests::Runner#run` method.
The `Flaky::FailuresLoggerFormatter` has a simple job of logging all failed examples to a file on disk when running all the
tests. The details of the failed example which are logged can be found in `TurboTests::Flaky::FailedExample.to_h`.
3. Once all the tests have been run once, we check the result for any failed examples and if there are, we read the file on
disk to fetch the `location_rerun_location` of the failed examples which is then used to run the tests in a new RSpec process.
In the rerun, we configure a `TurboTests::Flaky::FlakyDetectorFormatter` with RSpec which removes all failed examples from the log file on disk since those examples are not flaky tests. Note that if there are too many failed examples on the first run, we will deem the failures to likely not be due to flaky tests and not re-run the test failures. As of writing, the threshold of failed examples is set to 10. If there are more than 10 failed examples, we will not re-run the failures.
2023-12-12 18:18:27 -05:00
|
|
|
SCREENSHOT_PREFIX = "[Screenshot Image]: "
|
|
|
|
|
|
|
|
# Unfortunately this has to be parsed from the output because `ActionDispatch` is just printing the path instead of
|
|
|
|
# properly adding the screenshot to the test metadata.
|
|
|
|
def failure_screenshot_path
|
|
|
|
@failed_example_notification.message_lines.each do |message_line|
|
|
|
|
if message_line.strip.start_with?(SCREENSHOT_PREFIX)
|
|
|
|
return message_line.split(SCREENSHOT_PREFIX).last.chomp
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
nil
|
|
|
|
end
|
|
|
|
|
|
|
|
def rerun_command
|
|
|
|
@failed_example.command_string
|
|
|
|
end
|
|
|
|
|
|
|
|
def to_h
|
|
|
|
{
|
|
|
|
message_lines:,
|
|
|
|
description:,
|
2023-12-13 22:11:11 -05:00
|
|
|
exception_message:,
|
|
|
|
exception_name:,
|
DEV: Introduce automatic reruns to RSpec tests on Github actions (#24811)
What motivated this change?
Our builds on Github actions have been extremely flaky mostly due to system tests. This has led to a drop in confidence
in our test suite where our developers tend to assume that a failed job is due to a flaky system test. As a result, we
have had occurrences where changes that resulted in legitimate test failures are merged into the `main` branch because developers
assumed it was a flaky test.
What does this change do?
This change seeks to reduce the flakiness of our builds on Github Actions by automatically re-running RSpec tests once when
they fail. If a failed test passes subsequently in the re-run, we mark the test as flaky by logging it into a file on disk
which is then uploaded as an artifact of the Github workflow run. We understand that automatically re-runs will lead to
lower accuracy of our tests but we accept this as an acceptable trade-off since a fragile build has a much greater impact
on our developers' time. Internally, the Discourse development team will be running a service to fetch the flaky tests
which have been logged for internal monitoring.
How is the change implemented?
1. A `--retry-and-log-flaky-tests` CLI flag is added to the `bin/turbo_rspec` CLI which will then initialize `TurboTests::Runner`
with the `retry_and_log_flaky_tests` kwarg set to `true`.
2. When the `retry_and_log_flaky_tests` kwarg is set to `true` for `TurboTests::Runner`, we will register an additional
formatter `Flaky::FailuresLoggerFormatter` to the `TurboTests::Reporter` in the `TurboTests::Runner#run` method.
The `Flaky::FailuresLoggerFormatter` has a simple job of logging all failed examples to a file on disk when running all the
tests. The details of the failed example which are logged can be found in `TurboTests::Flaky::FailedExample.to_h`.
3. Once all the tests have been run once, we check the result for any failed examples and if there are, we read the file on
disk to fetch the `location_rerun_location` of the failed examples which is then used to run the tests in a new RSpec process.
In the rerun, we configure a `TurboTests::Flaky::FlakyDetectorFormatter` with RSpec which removes all failed examples from the log file on disk since those examples are not flaky tests. Note that if there are too many failed examples on the first run, we will deem the failures to likely not be due to flaky tests and not re-run the test failures. As of writing, the threshold of failed examples is set to 10. If there are more than 10 failed examples, we will not re-run the failures.
2023-12-12 18:18:27 -05:00
|
|
|
backtrace:,
|
|
|
|
failure_screenshot_path:,
|
|
|
|
location_rerun_argument:,
|
|
|
|
rerun_command:,
|
|
|
|
}
|
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|