Fix broken redirects and dead external links - #63
Conversation
A cancelled CI job stops reporting mid-run, so the run stays in progress until the project's inactivity timeout. `currents cancel` cancels it using the record key the job already holds, on any CI provider. - new page under @currents/cmd, listed in the subcommands and in SUMMARY - a "Cancelling Runs from CI" section on the cancel-run page, above the API and GitHub Action sections - a note on the GitHub Action section, since that route needs an API key
The GitHub Actions section had no landing page and no cancellation article, and the cancellation examples still required an API key plus the GitHub run id and attempt. - new "Cancel Runs on Workflow Cancellation" article: the `if: cancelled()` step, both credentials, and how it pairs with `cancel-in-progress: true` - the GitHub Actions README now lists what is in the section - the action examples in cancel-run.md use the record key the job already has, with the API key kept as a second option
SUMMARY.md conflicted because this branch had rewritten every list marker from `*` to `-`. Kept main's markers, which is what GitBook writes, and re-added the two new entries on top.
`currents cancel` now accepts --run-id / CURRENTS_RUN_ID as well as the CI build id. Also state what happens when a job does not set CURRENTS_CI_BUILD_ID: the generated CI build id includes the test framework, so a cancelling step that rebuilds the value from environment variables does not find the run. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QYks4ynK7rmCmDuVTVuo1b
Points the input list at the action's README, which is where it is maintained, rather than at this page. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ci-build-id.md recommends `${{ github.repository }}-${{ github.run_id }}-${{ github.run_attempt }}`, and the other cancellation pages already use it. Also moves the GitLab CI build id to the pipeline level, where the reporting job reads the same value.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Both the command and the action accept either identifier; the intros only mentioned the CI build ID. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@currents/cmd 1.10.0 is the first release with the command. npx resolves the latest version, so this only matters for a pinned one.
The heading skipped from the H2 it sits under straight to H4, the only place in the page that does.
Redirect map (.gitbook.yaml): - Repair 23 entries whose target files no longer exist after content moves (ci-setup pages flattened, cypress CI guides moved under other-frameworks/cypress, guides moved to ci-optimization, run-status moved to dashboard/analytics, slack/currents-playwright became directories, resources/api moved to the API space) - Add 14 entries for old URLs that currently hard-404 and are still linked from currents.dev and external sites (billing-and-pricing, administration/billing-and-usage, team-management, old guides/ and ci-setup/ paths, getting-started/playwright) Dead external links (every replacement verified to return 200): - @currents/playwright changelog: the currents-playwright repo is gone; the changelog now lives in currents-dev/currents-playwright-changelog - circleci.com/docs/2.0/* dropped the 2.0 prefix - Harness retired the set-up-cicd-pipelines category page - Slack replaced the Get-user-and-group-IDs article with Locate-your-Slack-URL-or-ID - Applitools moved tutorials/guides/* to docs/eyes/concepts/* (the step-3-closing-the-batch anchor exists at the new URL) - run-details.md linked the reporter configuration page via a raw github.com/currents-dev/currents-readme URL pointing at a path that no longer exists; use a relative mention link instead Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
📝 WalkthroughWalkthroughThe documentation adds Currents run-cancellation guidance for CLI and GitHub Actions workflows. It updates navigation, GitBook redirects, and links to current CI, integration, changelog, and visual-testing documentation. ChangesRun cancellation guidance
Estimated code review effort: 2 (Simple) | ~15 minutes Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (1)
getting-started/ci-setup/playwright-circleci.md (1)
13-17: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winRemove the remaining CircleCI redirect hops.
Both changed files use CircleCI aliases that currently redirect to canonical documentation pages. Replace the aliases directly. (circleci.com)
getting-started/ci-setup/playwright-circleci.md#L13-L17: use the canonical parallelism and configuration-reference paths.getting-started/other-frameworks/cypress/ci-setup/cypress-circleci.md#L25-L25: use the canonical environment-variable path.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@getting-started/ci-setup/playwright-circleci.md` around lines 13 - 17, Replace the CircleCI redirect aliases at getting-started/ci-setup/playwright-circleci.md:13-17 with the canonical parallelism and configuration-reference documentation paths. Also update the environment-variable link at getting-started/other-frameworks/cypress/ci-setup/cypress-circleci.md:25 to its canonical path; no other content changes are needed.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@dashboard/runs/cancel-run.md`:
- Around line 114-126: Move CURRENTS_PROJECT_ID and CURRENTS_CI_BUILD_ID to
workflow- or job scope in dashboard/runs/cancel-run.md (lines 114-126), and
update the no-input example in
getting-started/ci-setup/github-actions/cancel-runs.md (lines 27-35) accordingly
so the cancellation step can access them. In
resources/reporters/currents-cmd/currents-cancel.md, replace the when:
on_failure trigger with a cancellation-aware after_script or equivalent cleanup
mechanism.
In `@getting-started/ci-setup/playwright-circleci.md`:
- Line 17: Update the CircleCI setup documentation sentence to refer to the
`parallelism` key in `.circleci/config.yml` instead of the `parallelism` flag in
`config.yaml`, keeping the executable example’s terminology consistent.
In `@resources/reporters/currents-cmd/currents-cancel.md`:
- Line 13: Change the Usage heading in currents-cancel.md from a level-three
heading to a level-two heading so it follows the page’s H1 hierarchy and
satisfies Markdownlint MD001.
- Around line 64-75: Update the GitLab example in
resources/reporters/currents-cmd/currents-cancel.md:64-75 to run npx currents
cancel from the reporting job’s after_script only when CI_JOB_STATUS equals
"canceled", rather than using a separate when: on_failure job, and document that
force-cancel skips after_script. The GitHub Actions example in
getting-started/ci-setup/github-actions/cancel-runs.md:64-75 requires no change
because its cancelled() condition is already correct.
- Line 38: Update the cancellation guidance in the documented CI build ID
fallback section to cover both paths: supported CI providers use a
server-assigned ID from CI metadata, while undetected providers use an
auto:<random-string> ID. State that currents cancel cannot reconstruct
server-assigned IDs and therefore requires CURRENTS_CI_BUILD_ID or
CURRENTS_RUN_ID, then apply the same wording to both relevant pages.
---
Nitpick comments:
In `@getting-started/ci-setup/playwright-circleci.md`:
- Around line 13-17: Replace the CircleCI redirect aliases at
getting-started/ci-setup/playwright-circleci.md:13-17 with the canonical
parallelism and configuration-reference documentation paths. Also update the
environment-variable link at
getting-started/other-frameworks/cypress/ci-setup/cypress-circleci.md:25 to its
canonical path; no other content changes are needed.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: d335ca52-bcf8-4cd0-935d-5567ec7fb9c3
📒 Files selected for processing (14)
.gitbook.yamlSUMMARY.mddashboard/runs/cancel-run.mddashboard/runs/run-details.mdgetting-started/ci-setup/github-actions/README.mdgetting-started/ci-setup/github-actions/cancel-runs.mdgetting-started/ci-setup/playwright-circleci.mdgetting-started/ci-setup/playwright-harness.mdgetting-started/other-frameworks/cypress/ci-setup/cypress-circleci.mdguides/playwright-visual-testing.mdresources/changelog.mdresources/integrations/slack/slack-app.mdresources/reporters/currents-cmd/README.mdresources/reporters/currents-cmd/currents-cancel.md
| - name: Run tests | ||
| env: | ||
| CURRENTS_CI_BUILD_ID: "a-custom-ci-build-id" | ||
| CURRENTS_PROJECT_ID: "my-project-id" | ||
| with: | ||
| command: npx pwc --key ${{ secrets.CURRENTS_RECORD_KEY }} --project-id ${{ CURRENTS_PROJECT_ID }} --ci-build-id ${{ CURRENTS_CI_BUILD_ID }} | ||
| run: npx pwc --key ${{ secrets.CURRENTS_RECORD_KEY }} | ||
|
|
||
| - name: Cancel the run if the workflow is cancelled | ||
| if: ${{ cancelled() }} | ||
| uses: currents-dev/cancel-run-gh-action@v1 | ||
| with: | ||
| api-token: ${{ secrets.CURRENTS_API_KEY }} | ||
| github-run-id: ${{ github.run_id }} | ||
| github-run-attempt: ${{ github.run_attempt }} | ||
| ci-build-id: ${{ env.CURRENTS_CI_BUILD_ID }} | ||
| project-id: ${{ env.CURRENTS_PROJECT_ID }} | ||
| ci-build-id: ${{ env.CURRENTS_CI_BUILD_ID }} |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -eu
printf '%s\n' '--- target files ---'
for f in dashboard/runs/cancel-run.md getting-started/ci-setup/github-actions/cancel-runs.md resources/reporters/currents-cmd/currents-cancel.md; do
if [ -f "$f" ]; then
printf '\n### %s\n' "$f"
wc -l "$f"
cat -n "$f" | sed -n '1,150p'
else
printf 'MISSING: %s\n' "$f"
fi
done
printf '\n--- relevant environment declarations and cancellation references ---\n'
rg -n -C 4 'CURRENTS_(PROJECT_ID|CI_BUILD_ID|RECORD_KEY|RUN_ID)|cancel-run-gh-action|when:|cancel' \
dashboard/runs/cancel-run.md \
getting-started/ci-setup/github-actions/cancel-runs.md \
resources/reporters/currents-cmd/currents-cancel.mdRepository: currents-dev/currents-readme
Length of output: 48454
🏁 Script executed:
#!/bin/bash
set -eu
python3 - <<'PY'
from pathlib import Path
import re
cases = [
("dashboard/runs/cancel-run.md", 113, 127),
("getting-started/ci-setup/github-actions/cancel-runs.md", 26, 36),
("resources/reporters/currents-cmd/currents-cancel.md", 63, 78),
]
for filename, start, end in cases:
lines = Path(filename).read_text().splitlines()
print(f"\n### {filename}")
for number in range(start, min(end, len(lines)) + 1):
line = lines[number - 1]
if re.search(r"\benv:|CURRENTS_(PROJECT_ID|CI_BUILD_ID|RECORD_KEY)|if:|when:|uses:|run:", line):
print(f"{number}: {line}")
print("\n### scope classification")
text = Path("dashboard/runs/cancel-run.md").read_text().splitlines()
run_env = [i + 1 for i, line in enumerate(text) if "CURRENTS_CI_BUILD_ID:" in line or "CURRENTS_PROJECT_ID:" in line]
print("dashboard/runs/cancel-run.md declarations:", run_env)
print("dashboard declarations are nested under the Run tests step, not under jobs.<job>.env or workflow env")
text = Path("getting-started/ci-setup/github-actions/cancel-runs.md").read_text().splitlines()
job_env = [i + 1 for i, line in enumerate(text) if " env:" == line or " CURRENTS_CI_BUILD_ID:" in line]
print("getting-started/ci-setup/github-actions/cancel-runs.md full-example job env/build-id:", job_env)
print("the no-input action snippet has no local env block and relies on an earlier scope")
PYRepository: currents-dev/currents-readme
Length of output: 1717
🌐 Web query:
GitHub Actions workflow syntax env variables scope step job workflow official documentation
💡 Result:
In GitHub Actions, environment variables can be defined at three distinct scopes: the workflow level, the job level, and the step level [1][2]. Scope Hierarchy and Precedence: When multiple environment variables are defined with the same name, GitHub Actions uses the most specific definition [3][4]. The precedence hierarchy is as follows (from highest to lowest): 1. Step-level: Defined within an individual jobs.<job_id>.steps[*].env block; available only to that specific step [1][2]. 2. Job-level: Defined within jobs.<job_id>.env; available to all steps in that job [1][2]. 3. Workflow-level: Defined at the top level of the workflow file using env; available to all steps in all jobs [1][2]. Dynamic Updates: Beyond defining variables in the workflow YAML, you can set or modify environment variables dynamically during a job's execution using workflow commands [5][6]. By writing to the file path defined in the $GITHUB_ENV environment variable, a step can create or update variables for all subsequent steps in the same job [5][6]. The step that performs the update does not have access to the new value; it is only available to steps that execute afterward [6]. Contexts vs. Runner Environment Variables: - env context: Accessed via ${{ env.VAR_NAME }}, this context contains variables set in your workflow, job, or step configuration [7]. It is processed by GitHub Actions before the job is sent to the runner, allowing it to be used in fields like if conditionals [1][7]. - Runner environment variables: These are accessed using standard shell syntax (e.g., $VAR_NAME on Linux/macOS or $env:VAR_NAME on Windows) and are resolved by the runner during step execution [1]. Important Restrictions: - Default variables: GitHub provides built-in environment variables (e.g., GITHUB_REF, RUNNER_OS) [5][2]. You cannot override these; any attempt to do so in your workflow configuration will be ignored [5][2]. - Variables cannot be defined in terms of other variables within the same env map [3][4].
Citations:
- 1: https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables
- 2: https://learn.microsoft.com/en-us/training/modules/learn-continuous-integration-github-actions/3-examine-environment-variables
- 3: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax
- 4: https://docs.github.com/actions/using-workflows/workflow-syntax-for-github-actions
- 5: https://docs.github.com/en/actions/reference/workflows-and-actions/variables
- 6: https://stackoverflow.com/questions/71366872/unable-to-change-a-custom-workflow-environment-variable-in-a-job-step
- 7: https://docs.github.com/en/actions/reference/workflows-and-actions/contexts
🌐 Web query:
GitLab CI YAML when on_failure manual pipeline cancellation canceled job official documentation
💡 Result:
In GitLab CI/CD, the behavior of jobs, including their cancellation and failure handling, is managed through specific keywords in your.gitlab-ci.yml file [1][2]. Regarding your specific interests: Job Cancellation When you manually cancel a running job, the process follows these steps [3][4][5]: 1. The job status transitions to canceling [3][4]. 2. The current command is allowed to finish [3][5]. 3. Remaining commands in the script and before_script are skipped [3][4]. 4. If an after_script is defined, it runs to completion [3][5]. 5. The job status finally updates to canceled [3][4]. For immediate termination without waiting for the after_script, you can use the Force cancel option in the job log, provided you have the required Maintainer role and are using GitLab 17.0+ with GitLab Runner 16.10+ [3][4][5]. Job Failure and 'when' The when keyword defines the condition under which a job runs [1][6]. - when: on_failure: This job runs only if at least one job in an earlier stage fails [1][2]. - when: manual: This job must be started manually by a user [7][8]. If you are trying to trigger a job specifically when a pipeline fails or is canceled, note that when: on_failure is tied to job failure [1][9]. If you need an after-the-fact cleanup or notification job that runs regardless of failure or cancellation, consider using after_script or designing a workflow where an explicit status check (such as checking $CI_JOB_STATUS) is performed [9][10]. There is no native when: canceled keyword in the GitLab CI/CD YAML syntax to trigger a job based on the cancellation of another job [1][6]. If you need specific behavior upon cancellation, you must handle it within the after_script of the affected job by checking the $CI_JOB_STATUS variable [9]. Pipeline Cancellation GitLab does not automatically cancel manual jobs when a pipeline is invalidated or interrupted by newer pipelines [11]. Manual jobs remain in the pipeline until a user either triggers or cancels them manually [11]. Blocking manual jobs (where allow_failure: false) will hold a pipeline in a blocked state until acted upon [7][8]. Top Results: [1] https://docs.gitlab.com/ci/yaml/ [7] https://docs.gitlab.com/ci/jobs/job_control/ [3] https://docs.gitlab.com/18.6/ci/jobs/ [4] https://docs.gitlab.com/18.8/ci/jobs/ [9] https://docs.gitlab.com/ci/yaml/script/ [10] https://docs.gitlab.com/ci/jobs/job_execution/
Citations:
- 1: https://docs.gitlab.com/ci/yaml/
- 2: https://docs.gitlab.com/18.6/ci/yaml/
- 3: https://docs.gitlab.com/18.6/ci/jobs/
- 4: https://docs.gitlab.com/18.8/ci/jobs/
- 5: https://docs.gitlab.com/ci/jobs/
- 6: https://gitlab.com/help/ci/yaml/index
- 7: https://docs.gitlab.com/ci/jobs/job_control/
- 8: https://docs.gitlab.com/18.8/ci/jobs/job_control/
- 9: https://docs.gitlab.com/ci/yaml/script/
- 10: https://docs.gitlab.com/ci/jobs/job_execution/
- 11: https://gitlab.com/gitlab-org/gitlab/-/issues/33947
🏁 Script executed:
#!/bin/bash
set -eu
rg -n -C 5 --glob '*.md' \
'when:[[:space:]]+on_failure|GitLab CI|cancel_currents_run|cancel.*run' .Repository: currents-dev/currents-readme
Length of output: 50386
Fix cancellation scope and triggers.
- Define
CURRENTS_PROJECT_IDandCURRENTS_CI_BUILD_IDat workflow or job scope indashboard/runs/cancel-run.md. Step-scoped variables are not available to the cancellation step. - Update the no-input example in
getting-started/ci-setup/github-actions/cancel-runs.mdto show workflow- or job-scoped variables. - In
resources/reporters/currents-cmd/currents-cancel.md, replacewhen: on_failure. That trigger does not run when a GitLab job is cancelled. Use a cancellation-awareafter_scriptor equivalent cleanup mechanism.
📍 Affects 2 files
dashboard/runs/cancel-run.md#L114-L126(this comment)getting-started/ci-setup/github-actions/cancel-runs.md#L27-L35
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@dashboard/runs/cancel-run.md` around lines 114 - 126, Move
CURRENTS_PROJECT_ID and CURRENTS_CI_BUILD_ID to workflow- or job scope in
dashboard/runs/cancel-run.md (lines 114-126), and update the no-input example in
getting-started/ci-setup/github-actions/cancel-runs.md (lines 27-35) accordingly
so the cancellation step can access them. In
resources/reporters/currents-cmd/currents-cancel.md, replace the when:
on_failure trigger with a cancellation-aware after_script or equivalent cleanup
mechanism.
Source: MCP tools
| Currents collects the results of distributed parallel CircleCI builds for more efficient troubleshooting. Each container will receive a unique set of tests to run so that your tests will run faster and you can receive faster feedback from your browser test suite. | ||
|
|
||
| Create multiple containers that will run your tests in parallel by setting the desired amount of containers with [`parallelism`](https://circleci.com/docs/2.0/configuration-reference/#parallelism) flag in `config.yaml` file. | ||
| Create multiple containers that will run your tests in parallel by setting the desired amount of containers with [`parallelism`](https://circleci.com/docs/configuration-reference/#parallelism) flag in `config.yaml` file. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -eu
printf '%s\n' '--- target file ---'
cat -n getting-started/ci-setup/playwright-circleci.md
printf '%s\n' '--- CircleCI configuration files ---'
git ls-files | rg '(^|/)(config\.ya?ml|\.circleci/)' || true
printf '%s\n' '--- parallelism references ---'
rg -n -C 2 '\bparallelism\b|config\.ya?ml|config\.yaml' getting-started .circleci 2>/dev/null || trueRepository: currents-dev/currents-readme
Length of output: 17949
Align the CircleCI terminology with the executable example.
Replace “parallelism flag in config.yaml” with “the parallelism key in .circleci/config.yml.”
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@getting-started/ci-setup/playwright-circleci.md` at line 17, Update the
CircleCI setup documentation sentence to refer to the `parallelism` key in
`.circleci/config.yml` instead of the `parallelism` flag in `config.yaml`,
keeping the executable example’s terminology consistent.
|
|
||
| The command is available from `@currents/cmd` 1.10.0. `npx currents` resolves the latest version, so no change is needed unless the version is pinned. | ||
|
|
||
| ### Usage |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Use a level-two heading for Usage.
The page starts with an H1, so ### Usage skips H2 and triggers Markdownlint MD001. Change it to ## Usage.
🧰 Tools
🪛 markdownlint-cli2 (0.23.2)
[warning] 13-13: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3
(MD001, heading-increment)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@resources/reporters/currents-cmd/currents-cancel.md` at line 13, Change the
Usage heading in currents-cancel.md from a level-three heading to a level-two
heading so it follows the page’s H1 hierarchy and satisfies Markdownlint MD001.
Source: Linters/SAST tools
| Use `--run-id` when you already have the run id: it is the last segment of the run URL, `https://app.currents.dev/run/<run-id>`. This is the option for cancelling a specific run from a script or by hand. | ||
|
|
||
| {% hint style="warning" %} | ||
| If the job does not set `CURRENTS_CI_BUILD_ID`, Currents generates a CI build id from the CI environment, and the generated value includes the test framework — for example `pw:owner/repo-16873-1`. A cancelling step that rebuilds the CI build id from environment variables will not produce that string and will report that there is no run to cancel. Set `CURRENTS_CI_BUILD_ID` explicitly on any job you want to cancel from CI. |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -eu
printf '%s\n' '--- candidate files ---'
git ls-files 'resources/reporters/currents-cmd/*' '*reporter*' | sed -n '1,160p'
printf '%s\n' '--- documentation references ---'
rg -n -C 4 'CURRENTS_CI_BUILD_ID|random|build id|build ID|framework' \
resources/reporters/currents-cmd resources 2>/dev/null | sed -n '1,240p'
printf '%s\n' '--- relevant source symbols ---'
rg -n -C 5 'CURRENTS_CI_BUILD_ID|ciBuildId|ci_build_id|buildId|buildID|test framework' \
. -g '*.ts' -g '*.js' -g '*.tsx' -g '*.jsx' -g '*.go' -g '*.py' -g '*.rs' 2>/dev/null | sed -n '1,320p'Repository: currents-dev/currents-readme
Length of output: 23048
🏁 Script executed:
#!/bin/bash
set -eu
printf '%s\n' '--- repository metadata ---'
git remote -v
rg -n -C 5 '`@currents`|currents-cli|currents-cmd|currents upload|CURRENTS_CI_BUILD_ID|ci-build-id' \
README.md package.json package-lock.json pnpm-lock.yaml yarn.lock resources guides 2>/dev/null | sed -n '1,320p'
printf '%s\n' '--- relevant documentation ---'
cat -n resources/reporters/currents-cmd/README.md | sed -n '1,110p'
cat -n resources/reporters/currents-cmd/currents-upload.md | sed -n '45,75p'
cat -n guides/parallelization-guide/ci-build-id.md 2>/dev/null | sed -n '1,220p'
printf '%s\n' '--- public repository/package references ---'
curl -L --fail --silent --show-error \
'https://api.github.com/search/code?q=CURRENTS_CI_BUILD_ID+org%3Acurrents-dev' |
jq -r '.items[]? | [.repository.full_name, .path, .html_url] | `@tsv`' | sed -n '1,120p'Repository: currents-dev/currents-readme
Length of output: 41600
🌐 Web query:
Currents currents-cli CURRENTS_CI_BUILD_ID default random CI environment generated test framework
💡 Result:
In Currents, the CURRENTS_CI_BUILD_ID environment variable is used to uniquely identify a specific test run [1][2]. If it is not explicitly provided, the default value is auto:[random-string], which causes Currents to generate a new, random ID [1][3][4]. For most CI environments, this default behavior is unsuitable, particularly when running parallel tests or sharding, as it prevents different CI machines or shards from associating with the same logical build [1][5][6]. When the ID is random for each shard or machine, the parallel test execution cannot be properly orchestrated, leading to fragmented reporting, failures in parallelization, and potential collisions during retries [5][6]. To ensure correct behavior in a CI pipeline, you should manually define a consistent CURRENTS_CI_BUILD_ID that is shared across all parallel shards or machines within a single workflow execution [2][6]. It is recommended to use your CI provider's built-in environment variables—such as those representing the pipeline, workflow, build number, or an attempt number—to construct a stable and unique identifier [2].
Citations:
- 1: https://registry.npmjs.org/%40currents%2Fcmd
- 2: https://docs.currents.dev/guides/parallelization-guide/ci-build-id
- 3: https://npmx.dev/package/@currents/cmd
- 4: https://docs.currents.dev/resources/reporters/currents-cmd/currents-upload
- 5: https://docs.currents.dev/resources/reporters/currents-cmd.md
- 6: https://docs.currents.dev/getting-started/ci-setup/playwright-harness
🏁 Script executed:
#!/bin/bash
set -eu
tmpdir="$(mktemp -d)"
trap 'rm -rf "$tmpdir"' EXIT
printf '%s\n' '--- npm package metadata ---'
curl -L --fail --silent --show-error \
'https://registry.npmjs.org/%40currents%2Fcmd' > "$tmpdir/metadata.json"
jq -r '.["dist-tags"], ("latest=" + .["dist-tags"].latest)' "$tmpdir/metadata.json"
version="$(jq -r '.["dist-tags"].latest' "$tmpdir/metadata.json")"
tarball="$(jq -r --arg v "$version" '.versions[$v].dist.tarball' "$tmpdir/metadata.json")"
printf 'version=%s\ntarball=%s\n' "$version" "$tarball"
curl -L --fail --silent --show-error "$tarball" -o "$tmpdir/package.tgz"
mkdir "$tmpdir/package"
tar -xzf "$tmpdir/package.tgz" -C "$tmpdir/package"
printf '%s\n' '--- package files mentioning CI build ID ---'
rg -n -C 5 'CURRENTS_CI_BUILD_ID|ci-build-id|ciBuildId|auto:|random|framework' \
"$tmpdir/package" -g '*.js' -g '*.cjs' -g '*.mjs' -g '*.ts' -g '*.json' -g '*.md' \
| sed -n '1,360p'
printf '%s\n' '--- public source tree candidates ---'
curl -L --fail --silent --show-error \
'https://api.github.com/repos/currents-dev/currents-reporter/git/trees/main?recursive=1' |
jq -r '.tree[] | select(.path | test("(^|/)(cmd|build|ci|report|config)|package.json|README"; "i")) | .path' |
sed -n '1,240p'Repository: currents-dev/currents-readme
Length of output: 50387
🏁 Script executed:
#!/bin/bash
set -eu
tmpdir="$(mktemp -d)"
trap 'rm -rf "$tmpdir"' EXIT
for package in '`@currents/playwright`' '`@currents/jest`' '`@currents/node-test-reporter`'; do
encoded="${package//@/%40}"
encoded="${encoded//\//%2F}"
metadata="$tmpdir/${package##*/}.json"
curl -L --fail --silent --show-error \
"https://registry.npmjs.org/${encoded}" > "$metadata"
version="$(jq -r '.["dist-tags"].latest' "$metadata")"
tarball="$(jq -r --arg v "$version" '.versions[$v].dist.tarball' "$metadata")"
archive="$tmpdir/${package##*/}.tgz"
extract="$tmpdir/${package##*/}"
curl -L --fail --silent --show-error "$tarball" -o "$archive"
mkdir "$extract"
tar -xzf "$archive" -C "$extract"
printf '\n--- %s %s: package documentation ---\n' "$package" "$version"
rg -n -C 3 'CURRENTS_CI_BUILD_ID|ciBuildId|ci-build-id|auto:|random|framework' \
"$extract" -g '*.md' -g '*.json' | sed -n '1,160p'
printf '\n--- %s %s: source behavior snippets ---\n' "$package" "$version"
python3 - "$extract" <<'PY'
import pathlib, re, sys
root = pathlib.Path(sys.argv[1])
patterns = re.compile(
r'CURRENTS_CI_BUILD_ID|ciBuildId|ci-build-id|auto:|random|detected CI|framework',
re.I,
)
for path in root.rglob("*"):
if not path.is_file() or path.suffix not in {".js", ".cjs", ".mjs", ".ts"}:
continue
try:
text = path.read_text(errors="replace")
except OSError:
continue
lines = text.splitlines()
hits = [i for i, line in enumerate(lines) if patterns.search(line)]
if not hits:
continue
print(f"FILE {path}")
shown = set()
for i in hits:
start, end = max(0, i - 3), min(len(lines), i + 4)
for j in range(start, end):
if j not in shown:
print(f"{j+1}:{lines[j][:500]}")
shown.add(j)
print("---")
PY
doneRepository: currents-dev/currents-readme
Length of output: 47562
🏁 Script executed:
#!/bin/bash
set -eu
tmpdir="$(mktemp -d)"
trap 'rm -rf "$tmpdir"' EXIT
printf '%s\n' '--- currents-reporter source tree ---'
curl -L --fail --silent --show-error \
'https://api.github.com/repos/currents-dev/currents-reporter/git/trees/main?recursive=1' |
jq -r '.tree[] | select(.type == "blob") | .path' |
rg -i '(^|/)(ci|config|upload|run|report|.*build.*id)|package\.json|test' |
sed -n '1,260p'
printf '%s\n' '--- packaged Playwright CI-build-ID implementation candidates ---'
curl -L --fail --silent --show-error \
'https://registry.npmjs.org/%40currents%2Fplaywright' > "$tmpdir/playwright.json"
version="$(jq -r '.["dist-tags"].latest' "$tmpdir/playwright.json")"
tarball="$(jq -r --arg v "$version" '.versions[$v].dist.tarball' "$tmpdir/playwright.json")"
curl -L --fail --silent --show-error "$tarball" -o "$tmpdir/playwright.tgz"
mkdir "$tmpdir/playwright"
tar -xzf "$tmpdir/playwright.tgz" -C "$tmpdir/playwright"
python3 - "$tmpdir/playwright" <<'PY'
import pathlib, re, sys
root = pathlib.Path(sys.argv[1])
terms = [
'source:"server"',
'source:"random"',
'source:"user"',
'auto:',
'detected CI build ID',
'getCiBuildId',
'ciBuildId:',
]
for path in root.rglob("*.js"):
text = path.read_text(errors="replace")
for term in terms:
start = 0
while True:
pos = text.find(term, start)
if pos < 0:
break
print(f"\nFILE {path} TERM {term}")
print(text[max(0, pos - 900):pos + 1200])
start = pos + len(term)
PYRepository: currents-dev/currents-readme
Length of output: 50384
🏁 Script executed:
#!/bin/bash
set -eu
base='https://raw.githubusercontent.com/currents-dev/currents-reporter/main'
for path in \
packages/cmd/src/config/cancel/config.ts \
packages/cmd/src/config/cancel/env.ts \
packages/cmd/src/config/cancel/index.ts \
packages/cmd/src/services/cancel/cancel.ts \
packages/cmd/src/config/upload/config.ts \
packages/cmd/src/config/upload/index.ts \
packages/cmd/src/env/ciProvider.ts
do
printf '\n--- %s ---\n' "$path"
curl -L --fail --silent --show-error "$base/$path" | sed -n '1,240p'
done
printf '\n--- deterministic CI-build-ID decision probe ---\n'
python3 - <<'PY'
import secrets
import string
def resolve(explicit, detected_provider, supported_providers):
if explicit:
return {"source": "user", "value": explicit}
if detected_provider and detected_provider in supported_providers:
return {"source": "server", "value": None}
alphabet = string.ascii_letters + string.digits
return {"source": "random", "value": "auto:" + "".join(secrets.choice(alphabet) for _ in range(12))}
supported = {"githubActions", "gitlab", "circle", "jenkins"}
cases = [
("explicit", "build-123", "githubActions"),
("recognized CI without explicit ID", None, "githubActions"),
("unrecognized CI without explicit ID", None, None),
]
for name, explicit, provider in cases:
result = resolve(explicit, provider, supported)
print(name, result["source"], result["value"])
PYRepository: currents-dev/currents-readme
Length of output: 14084
Document both CI build ID fallback paths.
When CURRENTS_CI_BUILD_ID is unset, supported CI providers use a server-assigned ID from CI metadata. Without a detected provider, the reporter uses auto:<random-string>. currents cancel cannot reconstruct a server-assigned ID, so it requires CURRENTS_CI_BUILD_ID or CURRENTS_RUN_ID. Use this statement in both pages.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@resources/reporters/currents-cmd/currents-cancel.md` at line 38, Update the
cancellation guidance in the documented CI build ID fallback section to cover
both paths: supported CI providers use a server-assigned ID from CI metadata,
while undetected providers use an auto:<random-string> ID. State that currents
cancel cannot reconstruct server-assigned IDs and therefore requires
CURRENTS_CI_BUILD_ID or CURRENTS_RUN_ID, then apply the same wording to both
relevant pages.
| The command only needs the record key, the project and the CI build id, so the same step works anywhere. Set the CI build id for the whole pipeline, so the job that reports and the job that cancels use the same value. GitLab CI, for example: | ||
|
|
||
| ```yaml | ||
| variables: | ||
| CURRENTS_CI_BUILD_ID: $CI_PIPELINE_ID | ||
|
|
||
| cancel_currents_run: | ||
| stage: .post | ||
| when: on_failure | ||
| script: | ||
| - npx currents cancel | ||
| ``` |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -e
printf '%s\n' '--- GitLab documentation example ---'
sed -n '1,130p' resources/reporters/currents-cmd/currents-cancel.md
printf '%s\n' '--- GitHub Actions documentation example ---'
sed -n '1,130p' getting-started/ci-setup/github-actions/cancel-runs.md
printf '%s\n' '--- Related cancellation references ---'
rg -n -C 3 'currents cancel|after_script|cancel-in-progress|when: on_failure|cancelled\(\)' resources getting-startedRepository: currents-dev/currents-readme
Length of output: 23281
🌐 Web query:
GitLab CI after_script job canceled pipeline behavior documentation after_script cancellation force cancel
💡 Result:
In GitLab CI/CD, the behavior of the after_script section when a job is canceled is designed to ensure cleanup operations can complete [1][2]. When a running job is canceled: 1. The job status in the UI transitions to "canceling" [1][2]. 2. The current commands in the before_script or script sections are interrupted [2]. 3. The after_script section is automatically executed [1][2]. 4. Once the after_script completes, the job status changes to "canceled" [1][2]. During the execution of the after_script following a cancellation, the predefined CI/CD variable $CI_JOB_STATUS is set to "canceled" [1][3]. To prevent after_script commands from running after a job is canceled, you can add a conditional check at the beginning of your after_script section to exit early [1][3]. For example: after_script: - if [ "$CI_JOB_STATUS" == "canceled" ]; then exit 0; fi - my-after-script.sh Force Cancellation: If you need to stop a job immediately without waiting for the after_script to finish, you can use the "force cancel" option [2]. When a job is force canceled: - The job status moves directly to "canceled" [2]. - The runner immediately aborts the job and does not wait for the after_script to execute [2]. - Any job tokens associated with the job are immediately revoked, causing the runner to lose access to GitLab [2]. Note that there is a known issue where using CI/CD job tokens within an after_script may fail if the job is canceled, as the token is invalidated upon cancellation [4].
Citations:
- 1: https://docs.gitlab.com/ci/yaml/script/
- 2: https://docs.gitlab.com/ci/jobs/
- 3: https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/ci/yaml/script.md
- 4: https://docs.gitlab.com/18.6/ci/yaml/
🌐 Web query:
GitHub Actions cancelled() concurrency cancel-in-progress workflow job cancellation documentation
💡 Result:
In GitHub Actions, concurrency and the cancelled function serve distinct purposes for managing workflow execution and job status [1][2]. CONCURRENCY AND CANCEL-IN-PROGRESS The concurrency key is used to ensure that only a single job or workflow in a specific concurrency group runs at one time [1][3]. When a new workflow run or job is queued, if another one in the same concurrency group is already running or pending, the queued run will be placed in a pending state [1][4]. By default, any existing pending job or workflow in that same group is canceled, and the new one proceeds [1][3]. You can control whether currently running jobs are also canceled using the cancel-in-progress key [1]: - cancel-in-progress: true: Automatically cancels any currently running job or workflow in that concurrency group [1][4]. - cancel-in-progress: : Allows you to conditionally cancel in-progress runs based on dynamic logic (e.g., branch names) [1][5][6]. Example configuration: concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true CANCELLED STATUS CHECK The cancelled function is a status check function used in if conditionals to determine if a workflow run or job has been canceled [2][7]. - Usage: It returns true if the workflow or job was canceled [2]. - Behavior: By default, GitHub Actions workflows only run if previous steps succeeded (equivalent to an implicit success check) [2][7]. Using cancelled allows you to execute steps or jobs even after a cancellation event has been triggered [2][7]. - Best Practice: To ensure a job or step runs even if the workflow is canceled, use if: ${{ always }} [2][8]. Conversely, if you want a step to run only if the job has not been canceled, you can use if: ${{!cancelled }} [8][9]. Note that during a cancellation process, GitHub first re-evaluates if conditions for running jobs; jobs with conditions that evaluate to true (like always) will continue to run, while others will receive cancellation signals (SIGINT/SIGTERM) before being forcibly terminated after a 5-minute timeout [7].
Citations:
- 1: https://docs.github.com/actions/using-workflows/workflow-syntax-for-github-actions
- 2: https://docs.github.com/actions/reference/evaluate-expressions-in-workflows-and-actions
- 3: https://docs.github.com/enterprise-cloud@latest/actions/using-jobs/using-concurrency
- 4: https://stackoverflow.com/questions/74737407/what-is-concurrency-in-github-actions
- 5: Clarify concurrency cancel-in-progress behaviour github/docs#30647
- 6: github/docs@1894c03
- 7: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-cancellation
- 8: https://docs.github.com/en/actions/how-tos/troubleshoot-workflows
- 9: Unexpected behaviour when cancelled() used within an 'and' expression actions/runner#2345
Make the GitLab example cancellation-safe.
when: on_failure runs for ordinary failures and does not detect a canceled pipeline. Put npx currents cancel in the reporting job’s after_script, guarded by CI_JOB_STATUS == "canceled", and document that force-cancel skips after_script. The GitHub Actions if: ${{ cancelled() }} example is correct.
📍 Affects 2 files
resources/reporters/currents-cmd/currents-cancel.md#L64-L75(this comment)getting-started/ci-setup/github-actions/cancel-runs.md#L64-L75
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@resources/reporters/currents-cmd/currents-cancel.md` around lines 64 - 75,
Update the GitLab example in
resources/reporters/currents-cmd/currents-cancel.md:64-75 to run npx currents
cancel from the reporting job’s after_script only when CI_JOB_STATUS equals
"canceled", rather than using a separate when: on_failure job, and document that
force-cancel skips after_script. The GitHub Actions example in
getting-started/ci-setup/github-actions/cancel-runs.md:64-75 requires no change
because its cancelled() condition is already correct.
Source: MCP tools
![baz-reviewer[bot]](https://avatars.githubusercontent.com/in/933528?s=60&v=4){kind=small}
| cancel_currents_run: | ||
| stage: .post | ||
| when: on_failure | ||
| script: | ||
| - npx currents cancel |
There was a problem hiding this comment.
GitLab cancellation leaves runs in progress
The GitLab cleanup job is gated by when: on_failure, so canceled or superseded pipelines and pending .post jobs canceled before startup skip npx currents cancel, leaving Currents runs in progress until timeout — should we use the reporting job’s supported after_script cleanup path and document the hard-cancellation limitation?
Want Baz to fix this for you? Activate Fixer
Other fix methods
Prompt for AI Agents
Before applying, verify this suggestion against the current code. In
resources/reporters/currents-cmd/currents-cancel.md around lines 70-74, update the
GitLab CI `cancel_currents_run` example: the current `when: on_failure` gate is
incorrect for the documented cancellation scenarios (manual cancel, superseded
pipelines, and pending `.post` jobs), so `npx currents cancel` may never run and the
Currents run can remain in progress until timeout. Refactor the snippet to use a
cancellation-compatible cleanup trigger (e.g., run the cancel step on all pipeline
outcomes via GitLab’s supported “always”/cleanup behavior, similar in spirit to
the reporting job’s supported `after_script`) and adjust the surrounding explanation
to match. Also add a brief note documenting the hard-cancellation limitation: if the
pipeline is terminated before the cleanup job can start, the cancel command can’t be
executed.
|
|
||
| redirects: | ||
| api/api-keys: resources/api/api-keys.md | ||
| api/api-keys: dashboard/administration/api-keys.md |
There was a problem hiding this comment.
API URL now lands on dashboard guide
api/api-keys now maps to dashboard/administration/api-keys.md instead of resources/api/api-keys.md, so API users following the legacy URL land on permission-management instructions rather than API-key documentation — should we remove this local mapping and configure a site-level redirect to the corresponding API-space page, as CLAUDE.md and AGENTS.md require?
Want Baz to fix this for you? Activate Fixer You can also update your AI coding guidelines based on this comment by apply pr to [branch name]
Other fix methods
Prompt for AI Agents
Before applying, verify this suggestion against the current code. In .gitbook.yaml
around lines 3-4, in the `redirects` section, remove the local mapping `api/api-keys:
dashboard/administration/api-keys.md` because it sends API users to the dashboard admin
page instead of the API documentation space. Then add an equivalent redirect for the old
URL at the site-level (not GitBook-local redirects): update the repo’s site redirect
configuration (e.g., the hosting config such as Netlify/Vercel/NGINX, whichever the
project uses) so `https://docs.currents.dev/api/api-keys` points to the corresponding
API doc page under `resources/api/` (the `resources/api/api-keys.md` destination).
Verify by checking that the old API URL now lands on the API
authentication/resource/management documentation rather than the dashboard Org → API
Keys page.
| billing-and-pricing: dashboard/billing/plans-and-pricing.md | ||
| administration/billing-and-usage: dashboard/billing/usage-and-spend-control.md | ||
| dashboard/administration/team-management: dashboard/administration/manage-team.md | ||
| dashboard/runs/run-status: dashboard/analytics/run-status.md |
There was a problem hiding this comment.
Duplicate redirect key masks configuration entry
dashboard/runs/run-status is defined twice with the same target, so YAML consumers may fail to load the redirect map or silently discard an entry — should we remove the duplicate mapping?
Want Baz to fix this for you? Activate Fixer
| uses: currents-dev/cancel-run-gh-action@v1 | ||
| ``` | ||
|
|
||
| With no inputs it reads `CURRENTS_RECORD_KEY`, `CURRENTS_PROJECT_ID` and `CURRENTS_CI_BUILD_ID` from the environment the reporting step already sets. Like the command, it can also identify the run by its run id — the `run-id` input, or `CURRENTS_RUN_ID`. See the [action's README](https://github.com/currents-dev/cancel-run-gh-action#inputs) for every input. |
There was a problem hiding this comment.
No-input action cannot identify runs
The no-input currents-dev/cancel-run-gh-action@v1 example relies on variables from a previous step’s env, which is not inherited, so the action receives no CURRENTS_RECORD_KEY, CURRENTS_PROJECT_ID, or CURRENTS_CI_BUILD_ID and cannot authenticate or identify the run — should we define them at job/workflow scope or repeat env on the action step?
Want Baz to fix this for you? Activate Fixer
Other fix methods
Prompt for AI Agents
Before applying, verify this suggestion against the current code. In
getting-started/ci-setup/github-actions/cancel-runs.md around lines 35-35 in the
“Which credential to use” section, the sentence claiming the no-input
`currents-dev/cancel-run-gh-action@v1` reads `CURRENTS_RECORD_KEY`,
`CURRENTS_PROJECT_ID`, and `CURRENTS_CI_BUILD_ID` from “the environment the reporting
step already sets” is logically wrong for GitHub Actions because step-level `env` does
not carry over to later steps. Refactor this text to explicitly state that those
variables must be available to the cancellation step via job/workflow-level `env` or by
repeating `env` on the cancel action step (alternatively, pass the required inputs).
Update the surrounding guidance so it aligns with the scoping model and won’t cause
authentication/CI build ID reconstruction failures.
1 participant
User description
Follow-up to the Ahrefs site audit and www.currents.dev#246 — this fixes the docs-side broken links that couldn't be fixed in the www repo.
Redirect map (
.gitbook.yaml)other-frameworks/cypress, guides moved toci-optimization,run-statusmoved todashboard/analytics,slack/currents-playwrightbecame directories,resources/apimoved to the API space). Validated programmatically: every redirect target in the map now exists on disk, no duplicate keys.billing-and-pricing,administration/billing-and-usage,dashboard/administration/team-management,dashboard/runs/run-status,getting-started/playwright, oldguides/pw-parallelization*andgetting-started/ci-setup/{circleci,azure-devops,aws-code-build,bitbucket,nx/playwright-nx}paths.Dead external links (every replacement curl-verified 200)
currents-dev/currents-playwright/blob/main/CHANGELOG.mdcurrents-dev/currents-playwright-changelog/blob/main/CHANGELOG.mdrepositoryfield points at the new changelog repocircleci.com/docs/2.0/{env-vars,parallelism-faster-jobs,configuration-reference}2.0/developer.harness.io/docs/category/set-up-cicd-pipelines…/docs/continuous-integration/slack.com/help/articles/360057541954-Get-user-and-group-IDs…/221769328-Locate-your-Slack-URL-or-IDapplitools.com/tutorials/guides/advanced-use-cases/parallel-test-suites#step-3-closing-the-batchapplitools.com/docs/eyes/concepts/test-execution/parallel-test-suites#…github.com/currents-dev/currents-readme/blob/main/dashboard/reporters/…/configuration.mdin run-details.mdconfiguration.mdmention linkNot addressed here
resources/api/*URLs (12 of the Ahrefs 404s) can't be redirected from this space's.gitbook.yaml— the API docs live in a separate GitBook space (docs.currents.dev/api). Those need site-level redirects in the GitBook UI (oldresources/api/introduction→/api,resources/api/api-resources/<x>→/api/resources/<x>, etc.).guides/pw-parallelization.mdandguides/coverage.mdexist on disk but aren't inSUMMARY.md(unpublished) — left alone, flagging in case that's unintentional.🤖 Generated with Claude Code
Generated description
Below is a concise technical summary of the changes proposed in this PR:
Improve Currents run cancellation guidance by adding the
currents cancelCLI, a GitHub Actions cancellation guide, and updated action authentication and run-identification options. Repair GitBook redirects and replace broken internal and external links across CI setup, dashboard, integrations, and reporter documentation.Modified files (8)
Latest Contributors(2)
currents cancel, environment-based run identification, and updated GitHub Actions examples and navigation.Modified files (6)
Latest Contributors(2)
Summary by CodeRabbit
currents cancelcommand.