Firebase deploy trigger functions with dotenv not working

[Klabauterman]

[REQUIRED] Environment info

firebase-tools:
11.0.1

Platform:
macOS

[REQUIRED] Test case

I have added a .env file providing some variables:

STORAGE_UPLOAD_BUCKET=mycustombucket

Then i want to use this variable to create a trigger:

functions.storage
  .bucket(process.env.STORAGE_UPLOAD_BUCKET)
  .object()
  .onFinalize(async (object) => {
  console.log(process.env.STORAGE_UPLOAD_BUCKET);
  //DO STUFF...
});

The problem is that STORAGE_UPLOAD_BUCKET is not defined during the time of deployment, so the trigger gets deployed for the default bucket, not matter the value of STORAGE_UPLOAD_BUCKET.
But during runtime of the function it is then set.
The same problem exists for other triggers: You cannot use environment variables in firestore trigger paths.

[google-oss-bot]

This issue does not seem to follow the issue template. Make sure you provide all the required information.

[inlined]

The current solution does not inject environment variables during deploy time. For roadmap reasons (largely our alignment with Firebase Extensions) we need our "discovery" phase to happen without project-specific details like environment variables. Instead we have an upcoming feature where you can declare a parameter to your application and the deploy process will work with you to resolve those parameters.

You can follow along the status of that feature request here

[anantakrishna]

@inlined can you please explain why it was decided to provide runtime config in discovery phase (#4541), but not the environment variables?

[inlined]

We didn't remove Runtime Config from the discovery phase for reverse compatibility reasons, though it is going away in general (no ETA yet). We don't populate dotenv files during the discovery phase because our reconciliation between Functions and Extensions requires us to be able to determine the shape of the deployment generically outside the context of the project/environment variables. We'll do this by capturing dependencies on, for example, the storage bucket as a "parameter". This parameter will be enforced at deploy time (e.g. while interactive you'll be prompted for any missing values and in non-interactive mode a deployment will fail). It will be backed by dotenv files in Cloud Functions for Firebase and by the backend server in the case of Firebase Extensions.

[anantakrishna]

Thank you for explanation, @inlined.

The documentation specifically suggests to use global variables to reuse objects in future invocations. I wanted to initialize an instance of a bot object providing it with a TOKEN from the environment variables, but the current behaviour makes it impossible. Therefore, I have to resort to the lazy initialization from the function body. At least there is a workaround. But the documentation seems a bit misleading in this light.

Moreover, even after the parameters will come to the scene, still the deployment may fail due to the limitations of the deployment environment. For example, network access may be restricted. Am I clear? But I guess we cannot avoid this global context execution... At least some clarification may be added to the above mentioned documentation.

[inlined]

Yes, I would recommend checking the status of an environment variable before doing global initialization. So instead of:

const dbCon = new Database(process.env.DB_ADDRESS);

change to

let dbConn;
if (process.env.DB_ADDRESS) {
  dbConn = new Database(process.env.DB_ADDRESS);
}

We are considering giving a startup callback as well so you can have code that runs only when a new instance is launched in production.