Adds deploy --ignore-existing-functions command.

[IchordeDionysos]

Description

Addressing second use case mentioned in #877.

Scenarios Tested

firebase deploy --ignore-existing-functions worked and produced this output:
...
i functions: updating Node.js 6 function someFunction(us-central1)...
i functions: continuing with other deployments.
✔ functions[someFunction(us-central1)]: Successful update operation.
...

firebase deploy --force --ignore-existing-functions which errored out as expected:
Error:
You can not specify both --force and --ignore-existing-functions

Sample Commands

When there are functions missing in the current working directory the deploy command asks the user how to continue.
Either delete the missing functions OR to just ignore them.
With the Pull Request #949 only the first case was covered.

Because if you specify --non-interactive the command errors out.

Now adding the command --ignore-existing-functions you can explicitly tell firebase deploy to "continuing with other deployments." as it is possible in interactive mode.

firebase deploy --force delete existing functions
firebase deploy --ignore-existing-functions keep existing functions

[coveralls]

Coverage remained the same at 61.651% when pulling 4853b5c on IchordeDionysos:ignore-existing into f6169ff on firebase:master.

[heygambo]

Do I read it correctly that you cannot ignore existing functions in non interactive calls?

[IchordeDionysos]

No, if you run firebase deploy --non-interactive the functions throws an error

[heygambo]

No, if you run firebase deploy --non-interactive the functions throws an error

But you will be able to delete deployed functions that don't exist in the new source code in non interactive mode?

[IchordeDionysos]

Yes, exactly if you run firebase deploy --non-interactive --force then the deployed functions which are missing in the new source code are deleted from the project.
This flag was introduced in Pull Request #949.

To clarify what you can do in the interactive and non-interactive mode when the deployment script detects missing functions in the local source code:

Interactive mode:
You get prompted with this message:
Would you like to proceed with deletion? Selecting no will continue the rest of the deployments. (y/N)
You have basically 3 options I realized now:

1. You can say "Yes" (which deletes these functions)
2. You can say "No" (which keeps these functions)
3. If you do nothing for a while it's basically the same as 2. (no idea if this is the expected behavior)

Non-Interactive mode:
With the changes from this pull request included you have also 3 options:

1. Running firebase deploy --non-interactive abort the deployment
2. Running firebase deploy --non-interactive --force deletes the missing functions from the project
3. Running firebase deploy --non-interactive --ignore-missing-functions deploys only the functions found in the local source code

The third option in non-interactive mode is new in this pull request which now allows the same options as in interactive mode

[bkendall]

Thank you for the PR. Know this is on our radar, but adding flags has a bit more internal process required than you might expect. We'll keep this updated if this is something with which we want to move forward.

[bkendall]

@IchordeDionysos So, an initial conversation brought up this point. If you only want specific functions to be deployed (and others left alone), the solution that currently exists to do that is firebase deploy --only functions:[function] - more info in the docs. Does that, along with --force, solve the need you have in a similar way to this new flag?

[IchordeDionysos]

@bkendall Well if you have a lot of functions, you want to deploy at once this is not an ideal solution :)

[heygambo]

@IchordeDionysos For us everything works now! Thanks for adjusting the cli!

[DMZakaria]

I agree with @IchordeDionysos .
In my case, I have dev and prod environments and I use git-flow to handle versioning and features. Sometimes my developers need to test in dev directly so we deploy the functions from their branches but our continuous integration from dev branch always fails!
Now if we add the command --ignore-existing-functions w can explicitly tell firebase to deploy to "continuing with other deployments.".

[tkow]

Is there any progress? I hope this PR is merged.

[bkendall]

It's being discussed internally. I may have an update soon, but I can't make any promises (changing APIs, including our CLI flags, requires some internal review)

[fvcaputo]

I just found this after I made a similar feature request, just wanted to drop in and say this would also greatly help our process, hopefully it gets accepted! :)

[IchordeDionysos]

Hey,
I just wanted to drop in and ask about the status of the internal discussion.
I do totally understand that there have to be internal discussions about this. 😊

Especially as from my perspective there is no good abstraction of this flag which would work in different cases and commands (like --force) and my naming is kinda specific.
And I also understand that there might be something on your roadmap blocking such a feature. :)

[dinvlad]

Are there any updates or workarounds for this issue? We’d like to deploy some non-Firebase functions in the same project through Cloud Build, and would need to protect non-Firebase functions from being deleted by firebase deploy.

[mbleigh]

@dinvlad the Firebase CLI should ignore any functions that weren't deployed by the Firebase CLI, so you don't need --ignore-existing-functions for this to work.

[IchordeDionysos]

@mbleigh If this is the case (for the use case of @dinvlad and ours), then here is a script detailing the exact bug in the Firebase CLI:
https://gist.github.com/IchordeDionysos/51f86e8cd93851319651b959803ac04e

Just run it and follow the instructions and it'll guide you through what the exact problem here is.
You may need to create a blank project or otherwise even the first deploy will fail.

[IchordeDionysos]

The problem is in non-interactive mode there is absolutely NO way of telling the CLI for calling firebase deploy that it should just ignore the functions found in the project but not in the local source code.

You can only let them get deleted.
That's the whole point of this pull request.

For us, it would be totally okay to NOT have this flag but to alter the default behavior in non-interactive mode from the deploy failing to just ignore functions which are not found in the local source code as it was the case before #877 even became a problem. 😄

[dinvlad]

the Firebase CLI should ignore any functions that weren't deployed by the Firebase CLI

Could you clarify, does that apply only to interactive mode? Because our use case is non-interactive (Cloud Build).

[mbleigh]

It applies to both -- we leave functions deployed by other tools alone. Are you seeing otherwise?

…

On Thu, Jul 18, 2019, 6:36 AM Denis Loginov ***@***.***> wrote: the Firebase CLI should ignore any functions that weren't deployed by the Firebase CLI Could you clarify, does that apply only to interactive mode? Because our use case is non-interactive (Cloud Build). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#999?email_source=notifications&email_token=AAAAH7RMBPU2DPF27TXMR4DQABWXRA5CNFSM4GB5PPZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2IP5PY#issuecomment-512818879>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAAH7VALBCSYLKHTRLH5NLQABWXRANCNFSM4GB5PPZA> .

[dinvlad]

@mbleigh thanks, I wasn’t aware of that.
Looks like this line uses labels to filer out external functions:

firebase-tools/src/deploymentTool.js

Line 22 in dad143c

return labels && labels["deployment-tool"] && labels["deployment-tool"].indexOf(BASE) === 0;

[fs-wnelson]

What is the status of this PR?

[bkendall]

I kinda have an update: having a "product-specific flag" (--ignore-existing-functions) for a command that deals with multiple products (firebase deploy) makes this hard to accept. There's discussion internally on how to address this, but the general idea is that we should have a flag that could apply to any product that deploy controls. If anyone has some great ideas, I'm happy to hear them and float them towards the appropriate people.

[IchordeDionysos]

What about defensive, keep, no-delete, something general like mode (which would include both force and ignore).

[Nickman87]

This has been open for almost 2 years now, this is important for good CI, when can we expect a fix?

[cerkiner]

Still waiting for this. I have to codebases keep overwriting each other. One is an Angular project and it auto-generates a server-side renderer function and deploys. The second one has all API functions, auth and database triggers, schedules etc.
I prefer not to merge them.

[nilsreichardt]

Any updates?

[alecpirillo]

Would love to see this be implemented to solve the use cases already covered above.

[odelmas]

I would love it also

[icopp]

So... is this ever going to happen?

[JLRiiot]

Hey team, it would be great to have this merge however is there a workaround that we can use in the meantime?

[inlined]

It looks like this is stale; it still refers to src/deploy/functions/release.js even though that code has been rewritten. I'm not against this change, though I'll have to run the new flag through an API proposal process internally. We don't typically perform releases near a holiday, so there's a chance this will drag on into early in the new year.

[IchordeDionysos]

I haven't put in any work in to refactor it as there was never any conclusion from the internal design review!

So it would only make sense to refactor this if the design would be approved!

The missing flag actually forced us to setup some complicated deployments for it to work with out workflow.

[inlined]

Sounds good. FWIW, my design proposal differed a bit from your implementation. I allowed --force --ignore-existing-functions as a way of saying "take the default --force option everywhere (e.g. accept a price increase for increasing a min-instance allocation), except select "no" for deleting existing functions".

The early feedback was that it feels wrong to have a functions-specific flag on deploy. It's also generally an anti-pattern to let production get out of sync from a codebase (some feedback if you have a Good Reason to do this would be great). I'll keep posting updates as they happen.

[nilsreichardt]

@inlined

It's also generally an anti-pattern to let production get out of sync from a codebase (some feedback if you have a Good Reason to do this would be great).

I agree with you for production code. But this flag would be very helpful for our development environment.

Because when multiple developers are working on different features in different branches, they all have different cloud functions (related to the new features). If a developer wants to test the cloud function, he deploys the cloud function from his feature branch to the development environment. When now another PR got merged, triggers this our CI/CD pipeline which deploys all cloud function. This deletes the deployed cloud function from the feature branch (with the --force flag). Therefore, when the developer continues his work on his feature, he has always to redeploy his cloud function, because it could be that the cloud function got deleted by our CI/CD pipeline. And this is very annoying.

In terms of a staging or production environment, I agree with you. There would be this new flag a bad pattern.

[h11a]

I am trying to not delete functions that are already deployed when i deploy using bitbucket pipeline

I have the following:

            - pipe: atlassian/firebase-deploy:1.3.0
              variables:
                FIREBASE_TOKEN: $FIREBASE_TOKEN
                PROJECT_ID: $FIREBASE_PROJECT
                EXTRA_ARGS: '--only functions --ignore-existing-functions'

I am receiving the following error

INFO: Starting deployment of the project to Firebase.
error: unknown option '--ignore-existing-functions'
✖ Deployment failed.

is ignore-existing-functions actually an option? Can anyone see what is wrong.

[nilsreichardt]

@h11a My workaround to deploy functions and keep the existing functions, which are not included in the source code, is to use this command:

echo \"n\n\" | firebase deploy --only functions --interactive

[h11a]

@h11a My workaround to deploy functions and keep the existing functions, which are not included in the source code, is to use this command:

echo \"n\n\" | firebase deploy --only functions --interactive

Thanks! ended up having to install firebase-tools and run the command explicitly but its working well :)

[inlined]

Update: there's some pushback against having product-specific flags in firebase deploy. I've put this on the backburner because we instead have a feature in design that will hopefully be just as good. Stay tuned.

[korn101]

Crazy that this still remains unaddressed.

[inlined]

Sorry, we should actually have updated this thread.

We're not going to add --ignore-existing-functions any time in the forseeable future, but we are going to try to address things that we think are leading to this request. One feature launched at Google I/O, but we don't have a lot of marketing material for yet.

"Codebases" let you keep multiple directories or even repositories of your functions code. With this, you can deploy a single codebase at a time and the other functions which aren't part of that codebase won't be updated (or deleted). To enable codebases, add a fragment similar to the following to your firebase.json

"functions": [
  {
    "source": "functions",
    "codebase": "base",
  }, {
    "source": "my_other_functions",
    "codebase": "other"
  }
]

With this feature, you can say firebase deploy --only functions:base. Or if you have functions in separate git repos (e.g. multiple firebase.json files) you can say firebase deploy and it will ignore functions that don't match the codebases in firebase.json.

In the future, we will recognize that no functions in a codebase have been modified and skip their deployment entirely and the UX in our website will group functions by codebase.

[inlined]

I would like to remind of and ask you to follow our community guidelines for respectful communication.

The firebase CLI is a very large project and it was decided that adding one-off per-feature flags to firebase deploy will violate the fundamental design principles of this project. In general ad hoc flags for niche edge cases are opportunities to look for deeper design flaws. Instead of adding a one-off flag, we rearchitected our whole deployment pipeline to better support stronger isolation between functions which solves the only use cases for this flag that we would recommend a customer have. In the meantime, it also allows us to speed up deployments by detecting and skipping unmodified codebases. It also was the foundation of the "web frameworks" feature teased at Google I/O that allows you to use Functions + Hosting for modern web frameworks like Next.js

I'm really proud of the team and don't appreciate them being called a failure.

[ptrtht]

Hey @inlined,

1. The Firebase team has been doing an incredible job, particularly with the Python Firebase functions. Kudos to them!
2. Introducing the new Python Firebase functions framework has brought up a new use case for --no-delete:

I personally maintain two separate codebases for Python and Node.js based Firebase functions. However, every time I deploy either of them, I am prompted to delete the other codebase.

For instance, let's say you have two codebases, in which you have two functions: python_function and nodeFunction. When you run firebase deploy --only functions in your Node.js project, you are prompted to delete python_function, and vice-versa.

I don't think this is niche use case and as time goes on python for firebase functions is going to get more and more popular.

[inlined]

It sounds like you have the same codebase name for your node and python functions. If you have two different firebase.json and they have two codebases and they have separate names, then firebase deploy --only functions will deploy only that firebase.json's codebases and not the others. If that's not happening, there's been a regression.