Our data/common/users.csv has a password column holding ${TEST_MEMBER_PASSWORD} so the value is not in the repo. It works on my machine, where the variable is exported. On a colleague's machine, where it is only in projects/demo-shop/.env.staging, the logins fail — and not with a config error, just a failed login.
Is the dotenv layer supposed to reach dataset rows, or is the shell the only source there?
Accepted answer
It is supposed to reach them, and it does — dataset rows are interpolated with the same variable scope the YAML was, which is the dotenv layer with process.env merged over the top. So .env.staging is a valid home for that value.
Which means your colleague has a different problem, and the reason it looks like this one is the second half of the design: unresolved references in dataset rows are kept rather than thrown on. A row can legitimately contain ${...} that is not a variable at all, so failing the run would be wrong. The cost is that a typo travels all the way to the login form as the literal string ${TEST_MEMBER_PASSWORD} and surfaces as a rejected credential.
Check the spelling on both sides and check which file it is in — the .env.staging has to be at the repo root or in the project folder, and the -e has to be staging for .env.staging to be read at all.
Worth stepping back: if every row has the same password, the reference in the CSV is doing no work. Put the credential in the environment file as a vars: entry and let the steps read {{standardPassword}}; keep the dataset for the things that genuinely vary per row.
If the accounts differ per row and must not collide between workers, that is what the user pool is for rather than a shared column.
Hit this exact thing. What made it obvious was grepping the trace for the literal ${ — if it shows up in a request body or a form fill, it is an unresolved reference and not a wrong password.
Have the same question?
Ask it with the command you ran and the output you got, and it will be answered here.
Ask a question