envs/staging.yaml came out with:
api:
baseUrl: https://copilot.example.comThat is a different service entirely. The correct value is in the same .env.example file that analyze read:
line 40: SIM_AGENT_API_URL=https://copilot.example.com
line 79: NEXT_PUBLIC_API_URL=http://localhost:3000/apiSo it is not that it could not find the right one. It found both and chose the wrong one. Is there a way to tell it which variable to trust?
Accepted answer
No, and the reason it chose that one is not clever at all.
The env-var scan matches API_URL as a substring, so SIM_AGENT_API_URL is a candidate on equal footing with NEXT_PUBLIC_API_URL. The base URL is then assigned first-wins in file order. Line 40 beats line 79. Nothing ranks the canonical names above an arbitrary prefixed one, and nothing tells you in the report that there was more than one candidate.
Open issue, no fix yet, and no override flag. The workaround is to correct api.baseUrl in projects/<slug>/envs/<env>.yaml after applying — it is one line per environment and the file is yours from then on, so this is a one-time cost rather than a recurring one.
The thing to actually guard against is not noticing. Read the envs block in --report-only before you apply, and if the app has more than one *_API_URL in its env files, assume the guess is wrong until you have checked it.
Since it is first-wins by file order, moving NEXT_PUBLIC_API_URL above the others in .env.example does make it win. We did that, it worked, and I still think it is a daft thing to have to do to a file that other people read for other reasons — so if your .env.example is grouped logically, I would take Reeta's one-line fix in the env yaml instead and leave the app alone.
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