> ## Documentation Index
> Fetch the complete documentation index at: https://docs.peepsai.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Send Peeps variables to your CI

> Keep test logins and API keys in a Peeps environment and send them to your CI runs, masked in the job log, without adding them to your repository's secrets.

Your tests often need a login or an API key. Instead of adding them to your repository's secrets, you can keep them in a Peeps environment and send them to your CI runs. The [Peeps action](https://github.com/Peeps-Labs/peeps-action) masks each value in the job log and gives it to your tests as an environment variable.

> [!NOTE]
>
> This needs version 1.15.0 or later of the Peeps action. `Peeps-Labs/peeps-action@v1` gets it automatically. It works on GitHub Actions only for now: GitLab can't mask a value while a job runs, so there the action sets none of them.

## 1. Turn on Send to CI

1. In Peeps, open the project's **Settings** > **Environments**, then the environment, for example `dev`.
2. Add the variables your tests need, such as `E2E_USER_EMAIL` and `E2E_USER_PASSWORD`. Store a password or key as a **Password** or **API key** variable, so Peeps encrypts it.
3. Turn on **Send to CI** for each one.

Only stored values can be sent: **Text**, **Email**, **URL**, **Username**, **Password** and **API key** variables. Values Peeps makes at run time, files and payment cards can't. `BASE_URL` goes to runs Peeps starts already, so it has no switch. You need Contributor access to change the switch.

## 2. Use them in your workflow

**Runs Peeps starts** (from the run dialog, a schedule, an incoming webhook or your coding agent) get the variables of the environment they run in, before any test loads. You don't change anything.

**Runs your workflow starts**, such as a pull request's check or a push, name the environment with `peeps-environment`:

```yaml theme={null}
      - uses: Peeps-Labs/peeps-action@v1
        with:
          mode: ${{ inputs.mode }}
          session-id: ${{ inputs.sessionId }}
          peeps-environment: dev
```

If your repository is connected to more than one Peeps project with an environment of that name, add `peeps-project` with the project's acronym.

## 3. Read them in your tests

Each variable arrives under its name in Peeps:

```ts theme={null}
const email = process.env.E2E_USER_EMAIL!;
const password = process.env.E2E_USER_PASSWORD!;
```

In Python, read `os.environ["E2E_USER_EMAIL"]`.

## How they're kept safe

* Peeps sends them only to a job whose GitHub identity token proves it runs in a repository connected to that project. Fork pull requests get no token, so they get no variables.
* The action masks every value in the job log before anything else runs. The log lists the names it set, never the values.
* A variable your workflow sets itself wins, the same way `BASE_URL` does.
* Peeps never sends names that change how a program starts or that the CI system owns, such as `PATH`, `SHELLOPTS`, `NODE_OPTIONS`, `LD_PRELOAD`, `PYTEST_ADDOPTS`, `GITHUB_*` and `PEEPS_*`, and the action never sets them. **Send to CI** isn't offered for those names; rename the variable to send it.
* Everything without **Send to CI** stays in Peeps.

Any step of the job can read a variable the tests can, the same as a GitHub secret you put in `env:`. And a workflow on any branch can name any environment of the project, so anyone who can push a workflow change to the repository can read a variable you turn on. Send only what your tests need, and prefer test accounts to real ones.

When Peeps fixes a failing test, the agent writing the fix doesn't get these variables, so it can't run a test that needs a login yet. The run that checks the fix does get them.

If Peeps can't be reached, or the environment doesn't exist, the job shows a warning and the tests run without the variables.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.