Multiple projects via .firebaserc

[jthegedus]

The docs state:

The project to deploy to. If you leave this blank, be sure to check in a .firebaserc file so the CLI knows what project to deploy to.

How does the GitHub Action know which project alias to target? Does the projectId field support lookup from .firebaserc via alias name?

[jhuleatt]

Hi @jthegedus!

Currently, if you don't specify projectId, the action will look at your .firebaserc and deploy to your default project.

Support for other targets is discussed in #6

[jthegedus]

Am I correct in reading deploy targets support as different to multiple projects?

[newmskywalker]

Am I correct in reading deploy targets support as different to multiple projects?

I would say so. Targets are under the same project, just end up with different URL's

[mbleigh]

Deploy targets are intended to support multiple Hosting sites in the same project, not multiple projects. For instance, if you have a blog and a PWA each might have its own site and target.

[jhuleatt]

The projectId field does support aliases in .firebaserc, since under the hood this action just runs firebase hosting:channel:deploy --project=<projectId>, and that command allows either a project id or an alias to be used with the --project flag.

[jthegedus]

Okay, so the answer to the second part of my initial question:

Does the projectId field support lookup from .firebaserc via alias name?

is yes

Given that, I now understand the projectId field so support these scenarios:

1. if blank .firebaserc.default is used
2. if specified: a. if an alias, the corresponding value in .firebaserc is used b. if a projectId, the specific project is deployed to if possible

Given these scenarios, what is the expected path for switching firebaseServiceAccount (SA) with the project selected from .firebaserc? How would we program the switching of the SA our Action if we do not yet know which project is going to be selected? If multiple Firebase projects are supported, we will need to support multiple SAs to actually deploy to them

It feels like the action should be prescriptive in the naming convention used for the SAs so that it can handle this internally :thinking:

[jhuleatt]

The CLI's firebase init hosting:github command names the service account secret like FIREBASE_SERVICE_ACCOUNT_<PROJECT_ID> (for example, FIREBASE_SERVICE_ACCOUNT_MY_AWESOME_PROJECT).

If you need to dynamically swap projects in your workflow yaml file, if you use the CLI's naming convention for service account keys, it shouldn't be too tough to pick the correct service account secret for a project from a workflow yaml file.

Here's some (untested) yml that I think should work:

      # Decide the project ID you want to deploy to
      - id: set-project-id
        name: Set Firebase Project ID
        run: echo "::set-output name=project-id::$(echo my-awesome-project)"
      # generate the secret ID based on project ID (assuming you use the format FIREBASE_SERVICE_ACCOUNT_<PROJECT_ID>)
      - id: set-service-account-secret-id
        name: set Service Account secret ID
        run: echo "::set-output name=fb-sa-id::$(echo "FIREBASE_SERVICE_ACCOUNT_${{steps.set-project-id.project-id}}" | tr - _ | tr a-z A-Z)"
      # use the project ID and service account ID
      - uses: FirebaseExtended/action-hosting-deploy@v0
        with:
          repoToken: '${{ secrets.GITHUB_TOKEN }}'
          projectId: '${{steps.set-project-id.project-id}}'
          firebaseServiceAccount: '${{ steps.set-service-account-secret-id.outputs.fb-sa-id }}'

Does that make sense/solve your use case?

[jthegedus]

Yes, that does solve my use case, though my suggestion would be that the Action does all that internally if no firebaseServiceAccount is provided (given it has secrets.GITHUB_TOKEN I think this is possible?).

To close this issue, I would like to see the documentation explain the projectId field in more detail as the steps I outlined in https://github.com/FirebaseExtended/action-hosting-deploy/issues/20#issuecomment-714840029 are not currently clear.