Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[eas-cli] Combine .env and EAS environment variables for deploy command #2783

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

kitten
Copy link
Member

@kitten kitten commented Dec 20, 2024

Why

This allows --environment to be combined with local .env files, outputting a warning when any variables conflict since EAS environment variables will take precedence.

How

  • Update createManifestAsync to return manifest and conflicting variable names
  • Always call getEnv and merge variables into the env object
  • Output names when conflicts occurred

Test Plan

  • Tested locally

Copy link

Subscribed to pull request

File Patterns Mentions
**/* @szdziedzic, @khamilowicz, @sjchmiela, @radoslawkrzemien

Generated by CodeMention

@kitten kitten force-pushed the @kitten/feat/deploy-env-and-eas-env-simultaneously branch from c6eb6e7 to 04a5671 Compare December 20, 2024 14:22
Copy link

github-actions bot commented Dec 20, 2024

Size Change: +3.04 kB (+0.01%)

Total Size: 53.4 MB

Filename Size Change
./packages/eas-cli/dist/eas-linux-x64.tar.gz 53.4 MB +3.04 kB (+0.01%)

compressed-size-action

Copy link

codecov bot commented Dec 20, 2024

Codecov Report

Attention: Patch coverage is 0% with 14 lines in your changes missing coverage. Please review.

Project coverage is 52.49%. Comparing base (a1d086f) to head (0be4a4f).

Files with missing lines Patch % Lines
packages/eas-cli/src/worker/assets.ts 0.00% 11 Missing ⚠️
packages/eas-cli/src/commands/worker/deploy.ts 0.00% 3 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2783      +/-   ##
==========================================
- Coverage   52.51%   52.49%   -0.01%     
==========================================
  Files         583      583              
  Lines       22582    22589       +7     
  Branches     4452     4454       +2     
==========================================
  Hits        11856    11856              
- Misses      10691    10698       +7     
  Partials       35       35              

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

@kitten kitten force-pushed the @kitten/feat/deploy-env-and-eas-env-simultaneously branch from 18ea25b to 0be4a4f Compare December 20, 2024 19:13
Copy link

✅ Thank you for adding the changelog entry!

Copy link
Member

@wschurman wschurman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question for discussion: should this be the behavior for all commands that accept an --environment flag? (update, etc)

// NOTE: This is required for the .env resolution
process.env.NODE_ENV = 'production';
// Resolve .env file variables
const env: Record<string, string | undefined> = getEnv(params.projectDir).env;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is probably the question for @byCedric but doesn't the getEnv have a side effect of overriding process.env under the hood? I'm just curious?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh okay I see it will be fixed

Comment on lines +131 to 141
// Load EAS Env vars into `env` object, keeping track of conflicts
conflictingVariableNames = [];
for (const variable of loadedVariables) {
if (variable.value != null) {
if (env[variable.name] != null) {
conflictingVariableNames.push(variable.name);
}
env[variable.name] = variable.value;
}
}
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe it doesn't really matter if we override .env with EAS env vars here because npx expo export that generates worker code always uses .env with the highest priority either way. So this won't be the final env var resolution order in the final itself AFAIK because Expo CLI will load env vars from .env for the second time on its own afterwards.

I would say that maybe we should:

  1. just use .env env vars when --environment flag is not specified
  2. just use EAS env vars when --environment flag is specified and skip using .env env vars in Expo CLI by using EXPO_NO_DOTENV=1

what do you think?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We reasoned that during local development, it's very common to start adding new .env vars while still not being ready to update the remote env variables. Hence, we wanted for them to be combined.

Without the combination it's easy to get into a situation where you'd have to always go into the EAS environment variables and modify them (or add temporary env vars) while deploying, for the worker deployments to have the desired set during test deployments.

We can add the EXPO_NO_DOTENV flag for consistency though.

let env: Record<string, string | undefined>;
): Promise<CreateManifestResult> {
// NOTE: This is required for the .env resolution
process.env.NODE_ENV = 'production';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Won't it affect all of the actions happening afterward? I discussed it with @brentvatne some time ago and we generally disliked that NODE_ENV which can have many side effects is responsible for choosing which .env file to use. I believe we should unset it somewhere.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't set the environment outside the process itself, no. So it won't have any effects outside of this command

Screenshot 2025-01-07 at 11 09 14

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As per re. which environment is chosen, we don't really want any non-production related .env file from being chosen for the worker deployment, since logically the worker deployments are in a production environment once deployed

@szdziedzic
Copy link
Member

@kitten Oh okay I think this merging can actually work. You just need to always use EXPO_NO_DOTENV=1 when making calls to Expo CLI and make EAS CLI entirely responsible for lading env vars 👍

One more thing that remains is that this logic would be different from how eas update operates. eas update does:

  1. use .env env vars when the --environment flag is not specified
  2. use EAS env vars when the --environment flag is specified and skip using .env env vars in Expo CLI by using EXPO_NO_DOTENV=1

I'm not saying this is necessarily bad I just want to make you aware of it. Why do I think this can possibly be confusing? We have 2 commands that work really similarly (deploy and update) and they would do this very differently. It can be yet another way of handling env vars in EAS.

@szdziedzic
Copy link
Member

should this be the behavior for all commands that accept an --environment flag?

EAS Build is tricky here because in 50% of the cases people have .gitignored dotenv files that are not available later on EAS servers, so I'm not sure if we really want to start supporting .env files in eas build command.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants