Sean KaneandGitHub 4977a846be Write test results reports in between runs to preserve on crash (#9692)
## What changed?
testrunner writes intermediate JUnit XML reports after each completed
test attempt and enforces its own total deadline derived from the go
test -timeout flag.

## Why?
When a test run exceeds the GitHub Actions job timeout (40 min), the
entire process group is killed before the testrunner can write its final
merged XML, producing a synthetic junit.crash.xml showing
`functional-test (crash)`, with no visibility into actual test failures.

[Sample
run](https://github.com/temporalio/temporal/actions/runs/23567876357)
that actually had 108 failures on manual inspection

There are two distinct failure modes this addresses:

1. Killed between attempts — attempt 1 completes with failures, the
process is killed during attempt 2. Previously: no XML on disk. Now:
attempt 1's results survive in the intermediate file.
2. Go test timeout doesn't fire — the test binary hangs past its own
`-timeout=35m` (e.g. deadlocked goroutines). Previously: GitHub kills at
40 min with no XML. Now: the testrunner enforces the same 35m deadline
itself, kills `gotestsum`, extracts any `--- FAIL:` lines captured from
stdout, writes a report, and exits cleanly within the 5-minute buffer
before GitHub's kill.

## How did you test it?
- [X] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [X] added new unit test(s)
- [ ] added new functional test(s)

## Potential risks
The testrunner's context deadline fires at the same time as go test's
own -timeout. If both fire simultaneously, parseTestTimeouts (existing
path) and the new `ctx.Err()` check (new path) can both trigger. The
`ctx.Err()` check is guarded to only activate if the normal
timeout-panic path didn't already break the loop, so there is no
double-processing.
2026-03-30 16:04:48 +00:00
2026-03-13 18:50:16 +00:00
2025-04-07 18:42:37 -07:00

Temporal—durable execution platform

GitHub Release GitHub License Code Coverage Community Go Report Card

Introduction   •   Getting Started   •   Contributing   •   Temporal Docs   •   Temporal 101

Introduction

Temporal is a durable execution platform that enables developers to build scalable applications without sacrificing productivity or reliability. The Temporal server executes units of application logic called Workflows in a resilient manner that automatically handles intermittent failures, and retries failed operations.

Temporal is a mature technology that originated as a fork of Uber's Cadence. It is developed by Temporal Technologies, a startup by the creators of Cadence.

image

Getting Started

Download and Start Temporal Server Locally

Execute the following commands to start a pre-built image along with all the dependencies.

brew install temporal
temporal server start-dev

Refer to Temporal CLI documentation for more installation options.

Run the Samples

Clone or download samples for Go or Java and run them with the local Temporal server. We have a number of HelloWorld type scenarios available, as well as more advanced ones. Note that the sets of samples are currently different between Go and Java.

Use CLI

Use Temporal CLI to interact with the running Temporal server.

temporal operator namespace list
temporal workflow list

Use Temporal Web UI

Try Temporal Web UI by opening http://localhost:8233 for viewing your sample workflows executing on Temporal.

Repository

This repository contains the source code of the Temporal server. To implement Workflows, Activities and Workers, use one of the supported languages.

Contributing

We'd love your help in making Temporal great.

Helpful links to get started:

License

MIT License

S
Description
No description provided
Readme MIT
139 MiB
Languages
Go 85.4%
TypeScript 12.3%
ZAP 1%
Shell 0.6%
Dockerfile 0.4%
Other 0.2%