with one click
flake
Track Remotion CI flakes in issue
Menu
Track Remotion CI flakes in issue
Best practices for Remotion - Video creation in React
Release a new Remotion version
Fix newly added optional parameters, optional React props, and optional type/interface members in Remotion monorepo diffs by converting internal APIs to required nullable values and updating call sites. Use when a PR, review, or user asks to forbid new `foo?: T` / `param?: T` additions except for exported or documented public APIs where requiring the value would be breaking.
Wait for a Remotion pull request to become mergeable, handle merge conflicts, distinguish genuine CI failures from flakes, rerun flaky checks through the flake skill, and merge the PR. Use when asked to run /merge, merge a current PR after checks pass, or shepherd a Remotion PR through CI to merge.
Add a browser WebCodecs bug to the Remotion Mediabunny WebCodecs bugs docs page. Use when given a Chromium, WebKit, or Firefox issue URL that should be tracked in packages/docs/docs/mediabunny/webcodecs-bugs.mdx, especially when needing to look up the issue title, filing date, reporter, and resolution state before editing the MDX table.
Add a new sound effect to @remotion/sfx
| name | flake |
| description | Track Remotion CI flakes in issue |
Use this skill when a Remotion CI check fails and looks flaky, or when asked to run /flake.
Tracker issue: https://github.com/remotion-dev/remotion/issues/8375
Record flaky CI failures in issue #8375 and get the affected suite running again.
For every confirmed or likely flake:
Count.1, workflow/job, first-seen date, and evidence URL.Prefer gh because the GitHub app may not expose all Actions logs or write permissions.
If the user gave a PR:
gh pr view <pr-number> --repo remotion-dev/remotion --json number,title,headRefName,statusCheckRollup
gh pr checks <pr-number> --repo remotion-dev/remotion --watch=false
If the user gave a workflow run or job URL:
gh run view <run-id> --repo remotion-dev/remotion --json databaseId,attempt,displayTitle,event,headBranch,headSha,status,conclusion,workflowName,createdAt,updatedAt,url,jobs
gh api repos/remotion-dev/remotion/actions/jobs/<job-id>/logs
If there is no PR context, inspect recent open PRs and recent failed runs:
gh pr list --repo remotion-dev/remotion --state open --limit 30 --json number,title,headRefName,statusCheckRollup
gh run list --repo remotion-dev/remotion --workflow "Install and Test" --status failure --limit 20 --json databaseId,displayTitle,event,headBranch,headSha,conclusion,createdAt,url,workflowName
For rerun attempts, inspect the original attempt before deciding whether a failure was flaky:
gh api repos/remotion-dev/remotion/actions/runs/<run-id>/attempts/1/jobs --paginate
gh api repos/remotion-dev/remotion/actions/jobs/<failed-job-id>/logs
Treat a failure as a flake when at least one is true:
fetch failed, connection resets, package manager download failures, cache service failures, or runner provisioning errors.Do not record deterministic type errors, lint errors, snapshots, or test assertions caused by changed source behavior unless there is evidence they pass on retry.
Use a stable signature that groups repeats but stays specific enough to act on:
@remotion/it-tests#testssr.Good examples:
`oven-sh/setup-bun@v2.1.2` failed with `TypeError: fetch failed``delayRender()` timeout while running `Render video with browser instance not open` in `@remotion/it-tests#testssr`Read the issue body:
gh issue view 8375 --repo remotion-dev/remotion --json body --jq .body
Edit the full issue body, preserving the table. Always write the replacement Markdown to a temporary file and use --body-file; do not pass multiline Markdown inline.
Table format:
| Count | Signature | Workflow / job | First seen | Evidence |
| ---: | --- | --- | --- | --- |
| 1 | `signature` | `Workflow` / `Job` | YYYY-MM-DD | https://github.com/remotion-dev/remotion/actions/runs/... |
When incrementing an existing row:
Count unless the evidence link is dead or less useful than the new one.First seen as the earliest known date.When appending a row:
Verify after editing:
gh issue view 8375 --repo remotion-dev/remotion --json body --jq .body
Prefer rerunning only failed jobs:
gh run rerun <run-id> --repo remotion-dev/remotion --failed
If only one known flaky job needs a rerun and the run is complete:
gh api --method POST repos/remotion-dev/remotion/actions/jobs/<job-id>/rerun
If a flaky suite is still in progress and waiting would block the task, abort that workflow run and rerun failed jobs after cancellation is visible:
gh run cancel <run-id> --repo remotion-dev/remotion
gh run watch <run-id> --repo remotion-dev/remotion --exit-status
gh run rerun <run-id> --repo remotion-dev/remotion --failed
If gh run watch exits non-zero because cancellation made the run fail, continue to rerun failed jobs.
Summarize: