[worker] warn on unknown build environment

[gwdp]

Why

A workflow job with an environment that doesn't exist (e.g. staging, vs development/preview/production) gets no warning. It silently resolves to zero environment variables and fails later in a confusing, unrelated-looking way (e.g. the app config failing to read).

How

Warn in the "Spin up build environment" phase when the job's environment isn't development/preview/production.

Test Plan

Ran this job against a local worker:

jobs:
  verify_fingerprint_job_outputs:
    name: Verify fingerprint job outputs
    type: custom
    environment: staging
    runs_on: linux-medium
    steps:
      - run: echo "=== test job ==="

[gwdp]

• [worker] warn on unknown build environment #3952 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 59.27%. Comparing base (9247f3c) to head (bf57252).
⚠️ Report is 8 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3952      +/-   ##
==========================================
+ Coverage   59.18%   59.27%   +0.10%     
==========================================
  Files         935      936       +1     
  Lines       41075    41159      +84     
  Branches     8648     8675      +27     
==========================================
+ Hits        24306    24393      +87     
+ Misses      16674    16666       -8     
- Partials       95      100       +5     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

Subscribed to pull request

File Patterns	Mentions
**/*	@douglowder

Generated by CodeMention

Warning: The preamble and epilogue options in commentConfiguration are deprecated. Use template instead.

[gwdp]

started with a new build phase but thought it was overkill and moved here. Let me know if you have any different thoughts

[github-actions]

⏩ The changelog entry check has been skipped since the "no changelog" label is present.

[sjchmiela]

We support custom environments, so specifying a not-known environment is not an issue per se as long as the user has environment variables in that environment?

Initially I thought we might color the environment pill yellow on workflow run page if the environment has no variables, but that would color it yellow if a user does not use EAS Environment Variables at all which is bad?

Maybe we do this ^ but only if environment is not one of the known environments? Or sth like that

[gwdp]

Tysm for the review! I missed the custom environments UI, and the www enum only listing dev/preview/prod made me assume they weren't a thing. Should've asked claude:rolling_on_the_floor_laughing:

Agreed that false warnings would be bad here. I think the cleaner fix is to have www set a flag (that's where the resolved vars actually live from what I see) saying the environment matched no variables, and have the worker just react to it instead of hardcoding the known-environments list. wdyt?

[sjchmiela]

I think it depends on where do we want the flag to live!

We could have it be a column / flag (property in some new JSONB column) on a Workflow Job. Then, based on the flag supplied at creation time we would later show the warning in the UI or not. This requires adding a new field.

We could have it be something calculated dynamically, like we open workflow run page, website gets the list of environments used in the workflow run, website asks www if those environments currently have variables assigned to them. Bad thing about it is that this may drift as we don't have a notion of "environment variables at a given point in time".

We could have it be, as you suggest, a flag on the job, but then we can't show the warning on non-VM jobs!

I think the first is the most correct one.

[gwdp]

At first I was okay with not showing it for non-VM jobs, but reasoning through, the warning I'm showing was never the perfect place imho. Further on, maybe a new warningson WorkflowJob would allow us to have those warnings issues on www and more flexibility on how to show? (Maybe in the annotations?). Will dig further but sharing in case you have a different take or any input