> For the complete documentation index, see [llms.txt](https://docs.currents.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.currents.dev/resources/reporters/currents-cmd/currents-upload.md).

# currents run upload

Upload test results of the Jest and Node.js test runner reporters, JUnit XML reports or Cypress run results to Currents with the currents run upload command, with environments and Currents Actions

`currents run upload` uploads test results to Currents. It reads the reports written by a Currents reporter:

* the [Jest reporter](/resources/reporters/currents-jest.md)
* the [Node.js test runner reporter](/resources/reporters/currents-node-test-reporter.md)

With `--input-format`, it first converts JUnit XML reports or Cypress run results to the Currents format, then uploads them. See [Upload JUnit XML reports](/resources/reporters/currents-cmd/currents-convert.md) and [Upload Cypress 13+ Results](/getting-started/other-frameworks/cypress/upload-cypress-13-results.md).

For [Detox](/getting-started/other-frameworks/jest/detox-+-jest.md) runs, the command also uploads the videos, screenshots and logs that Detox recorded, attached to the test attempt they belong to, and `detox.trace.json`. Run it after `detox test` exits.

## Usage

```bash
npx currents run upload --key <record-key> --project-id <project-id> --ci-build-id <ci-build-id>
```

The command uploads the reports in `--report-dir`. Without it, the command uploads the newest folder in `.currents` in the current folder, which is where the reporters write by default. It prints `Run created:` and the link to the run.

For example, with Jest:

```bash
npx jest --reporters=@currents/jest --reporters=default
npx currents run upload --key <record-key> --project-id <project-id> --ci-build-id <ci-build-id>
```

## Options

`--key` and `--project-id` are required. The other options are optional.

| Option                   | Environment variable          | Description                                                                                                                                                                                         |
| ------------------------ | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `-k, --key <record-key>` | `CURRENTS_RECORD_KEY`         | The [Record Key](/guides/record-key.md).                                                                                                                                                            |
| `-p, --project-id <id>`  | `CURRENTS_PROJECT_ID`         | The project ID from the Currents dashboard.                                                                                                                                                         |
| `--ci-build-id <id>`     | `CURRENTS_CI_BUILD_ID`        | The CI build ID to record the run with. By default it is taken from the CI environment, or a random value. See [CI Build ID](/guides/parallelization-guide/ci-build-id.md).                         |
| `--report-dir <folder>`  | `CURRENTS_REPORT_DIR`         | The folder of the reports to upload. Default: the newest folder in `.currents`.                                                                                                                     |
| `-t, --tag <tag>`        | `CURRENTS_TAG`                | Tags to add to the run. Comma-separated or repeated.                                                                                                                                                |
| `--environment <name>`   | `CURRENTS_ENVIRONMENT`        | The [environment](/guides/environments.md) to label the run with, for example `staging`. When both are set, `--environment` is used. Requires `@currents/cmd` 2.3.0+.                               |
| `--machine-id <id>`      | `CURRENTS_MACHINE_ID`         | The ID of the machine that ran the tests. Default: a random value.                                                                                                                                  |
| `--disable-title-tags`   | `CURRENTS_DISABLE_TITLE_TAGS` | Do not read tags from test names. For example, `Test name @smoke` is not tagged with `smoke`. Default: `false`.                                                                                     |
| `--remove-title-tags`    | `CURRENTS_REMOVE_TITLE_TAGS`  | Remove tags from test names in Currents. For example, `Test name @smoke` becomes `Test name` in the dashboard. Default: `false`.                                                                    |
| `--fail-on-failures`     | `CURRENTS_FAIL_ON_FAILURES`   | Exit with 1 after the upload when a test failed, and list the failed tests. A test that a Currents Action quarantined or skipped does not count. Default: `false`. Requires `@currents/cmd` 2.3.0+. |
| `--debug`                | `CURRENTS_DEBUG`              | Print debug logs. Keys are hidden in them. Default: `false`.                                                                                                                                        |

The options for converting JUnit XML reports (`--input-format`, `--input-file`, `--framework`, `--framework-version`, `--output-dir`) are on [Upload JUnit XML reports](/resources/reporters/currents-cmd/currents-convert.md).

## Currents Actions

`currents run upload` applies the project's [Currents Actions](/guides/currents-actions.md) to the results before it sends them (`@currents/cmd` 2.3.0+). The tests already ran, so each attempt keeps its result, errors and artifacts:

* a skip action marks the test as skipped
* a quarantine action marks a failed test as skipped
* a tag action adds its tags to the test

The dashboard shows which action changed each test. Actions with regex or date conditions are not applied yet. If the command cannot get the actions, it prints `Failed to fetch the project actions, uploading without them` and uploads the results without them.

### Fail the CI job when a test failed

A quarantined test still fails the test command. To let quarantine decide whether the CI job fails, let the test command pass and fail the job from the upload with `--fail-on-failures`:

```bash
npx detox test || true
npx currents run upload --key <record-key> --project-id <project-id> --fail-on-failures
```

The upload exits with 1 when a test failed that no action quarantined or skipped.

## Examples

Add the tags `tagA` and `tagB` to the run:

```bash
npx currents run upload --key <record-key> --project-id <project-id> --ci-build-id <ci-build-id> --tag tagA --tag tagB
```

Upload the reports of another folder:

```bash
npx currents run upload --key <record-key> --project-id <project-id> --ci-build-id <ci-build-id> --report-dir <report-dir>
```

## Troubleshooting

If the command finds no reports, it prints the folder it looked in:

```
No reports found: there is no report folder in "<path>/.currents". Run the tests with a Currents reporter first, or pass --report-dir with the folder of the reports.
```

Run the test command with the Currents reporter before `run upload`, in the same folder, or pass `--report-dir`.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.currents.dev/resources/reporters/currents-cmd/currents-upload.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
