Add support for service account in functions.runWith

[egor-miasnikov]

Description

This PR adds support for the service account inside runWith.
My corresponding PR in firebase-tools: #2580

Code sample

functions
      .runWith({
        serviceAccountEmail: '[email protected]'
      })
      .auth.user()
      .onCreate((user) => user);

[samtstern]

@egor-miasnikov thank you for this pull request! All API changes to Firebase SDKs require us to go through an internal API review process, so my apologies in advance this may take a bit longer than expected.

@mbleigh do you want to sponsor this one as well?

[mbleigh]

@egor-miasnikov thanks for the PR! I'll need to sponsor this through internal API review, which will take a bit of time, but a few things:

1. You'll need to make a corresponding change in firebase/firebase-tools to support the new option (see here for recent example)
2. As with the new vpcConnector setting, I'd like to make it possible for this to be project-agnostic. So when you add the firebase-tools PR, let's have a pattern of:
   1. If serviceAccountEmail is a full email, pass it through as-is.
   2. If serviceAccountEmail does not contain an @, automatically append @${project_id}.iam.gserviceaccount.com to the value.

This way I can deploy to multiple projects with the same value so long as I've set it to the name of a service account that exists in each project.

[samtstern]

@mbleigh the firebase-tools PR is already up:
firebase/firebase-tools#2580

[egor-miasnikov]

Hey @mbleigh thank you for you comments! point 1 already done, thanks @samtstern ;) Regarding point 2 I propose validate user input by '@' and if ok set as-is otherwise skip input and based on current functionality will be set default service account from the project. Or if we are going to generate email based on name maybe we would like to rename property to 'serviceAccount', what do you think? But I think it will be not so obviously relatively what need to set in it:)
PS: in all my projects where I used to use firebase we controled environment separately and inside the function we use 'some-sa@{project_id}.iam.gserviceaccount.com'

[mdreizin]

@mbleigh Did you have a chance to review this PR?

[mdreizin]

@mbleigh @samtstern Could anybody from Firebase Team also look at this PR as well? Has it passed internal API review process?

[samtstern]

@mdreizin sorry about the silence here! I'm going to look into this and see what's going on. @mbleigh definitely wrote up the API proposal and sent it out for approval but I don't see the final decision anywhere (which is odd, it shouldn't take this long).

[egor-miasnikov]

Hey @samtstern @mbleigh, any updates with the internal proposal?

[joehan]

Hey all, sorry for the delay on this, the API review slipped past us for a bit, but it is approved now! There were a few other changes to the API requested, so I'm going to make those this week and do some testing. I'm hoping to get this released sometime later this week if all goes well. Thanks for the contribution and patience!

[mbleigh]

The approved API for this was actually to explicitly put a trailing @ to indicate that it is a named service account for the current project. So the else should be moved up to an else if that comes before this something like:

    else if (options.serviceAccount.endsWith('@')) {
      if (!process.env.GCLOUD_PROJECT) {
        throw new Error(
          `Unable to determine email for service account '${options.serviceAccount}' because process.env.GCLOUD_PROJECT is not set.`
        );
      }
      trigger.serviceAccountEmail = `${options.serviceAccount}${process.env.GCLOUD_PROJECT}.iam.gserviceaccount.com`;
    }

[joehan]

@mbleigh Fixed this up and retested all 4 scenarios ('default', 'service-account@', '[email protected]', and 'something-invalid'): the first three work as expected, and the fourth throws an error listing the valid options. PTAL!