firebase-tools: Deleting in non-interactive mode is not possible

Version info

“firebase-tools”: “4.1.1”

Platform Information

OS X and Bitbucket Pipelines CI

Steps to reproduce

In Bitbucket pipelines CI, using non-interactive mode with env variables firebase use myproject firebase deploy with 5 functions in index.js

In a later PR firebase deploy with just 4 functions in index.js

Expected behavior

  1. The full firebase deploy removes the “5th” function that is no longer in the latest index.js
  2. No manual steps/CLI commands are required (like in previous versions of firebase tools)

Actual behavior

Error: The following functions are found in your project but do not exist in your local source code: … list of functions … Aborting because deletion cannot proceed in non-interactive mode. To fix, manually delete the functions by running:

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 7
  • Comments: 23 (10 by maintainers)

Commits related to this issue

Most upvoted comments

Sure: We’re constantly refactoring old functions and often replacing (swapping https onRequest for onCall for example). It’s easier for us to delete the old function and add a new one. Sometimes we simply aren’t using the function anymore, and want it gone. We wouldn’t delete a function every week, but now that it’s not possible to do via CI, it means we have to add a manual step in review to manually delete before merging and auto deploying. It also means at least two developers need write access to our production functions, which we’re trying to get away from for peace of mind. If we had something like firebase deploy --allow-deletes and we maintain a good review process, our entire Dev team can freely create/update/delete anything without waiting on me to open up production CLI on my laptop while I’m working on something else.

I can understand why the default would be not to delete, but we’re suprised it’s not possible/blocked in non-interactive mode, assuming most people in that mode are thoroughly reviewing before deploying like we are?

Here’s the “hack” that we are using to only upsert function (not delete others):

echo "n\n" | firebase deploy --only functions --interactive --token $FIREBASE_TOKEN

Would also appreciate having and explicit option such as --no-delete rather than relying on the question never changing 😏

Not sure if anyone suggested it already. Most of the users seem to prefer a flag where functions not present will get deleted.

This is not always the option everyone want’s to have. For example, we would like to have a flag, which allows us to just ignore these functions. So the functions won’t get an update or get deleted.

For example, if someone created a new function in a feature branch and deployed it using firebase deploy --only functions:functionName for testing purposes. This won’t affect any other function in production use.

And then someone tries to deploy a new version, then our CI pipeline would start and call the command firebase deploy --ignore-missing-functions, then the deploy would update all present functions, create missing functions, but would not update or delete the function functionName.

I see the benefit of a flag to get back the old behaviour, so both behaviours would be great to have in my opinion. Either delete missing functions or just ignore them.

@laurenzlong could a flag be added to allow deletions in non-interactive mode? Deleting functions by hand in CLI for us is way less safe and inconvenient versus a good review/merge policy + CI deployments

@mbleigh Is there any option to not delete any function when I run firebase deploy?

For example, if I have 2 separate repositories with totally different functions which all deploy to the same Functions project.

So e.g.: I have repos

  • “frontend”, with the function:
    • languageRedirector
  • “backend”, with:
    • onUserAuthenticated

Now if I run firebase deploy from the “frontend” repo I want to update only languageRedirector and if I run firebase deploy from the “backend” repo I want to update only onUserAuthenticated

Is this possible?

We will be adding an option to force deletes of missing functions soon. We’ve heard the feedback, hopefully this helps. The default behavior will remain the same.

On Fri, Oct 12, 2018, 5:06 AM Solomon Engel <notifications@github.com wrote:

@laurenzlong https://github.com/laurenzlong is this being addressed?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/firebase/firebase-tools/issues/877#issuecomment-429303503, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAD_npvEeL-UEG_Q5YNtNylQCi_9hKKks5ukIWtgaJpZM4WCBfg .

We have exactly the same issue. It would help as a lot as well. We had to give up our automated deployments using Google Cloud Builder because of the update.

Thanks for the feedback Alan, I’ll open up the discussion internally about this.

Still no way to confirm in any case in non-interactive mode?

A -yjust like in apt install -y foowould be nice

firebase deploy -y

@Retsuki Do you have firebase tools as a dependency?

It would really be nice to just have an ignore flag for this 😐

Another “hack” alternative is to explicitly pass all function names after reading them from the index.ts

firebase deploy --token $FIREBASE_TOKEN --only functions:`sed -n "s/exports\.\(\w*\).*$/\1/p"  functions/index.ts | paste -s -d, -`

Explanation

Same here. Because we have lots of triggers and often times we need to move user database from prod to dev project for investigation and troubleshooting we need a way to disable all the triggers during json import. And the only way to disable triggers we came up is to actually delete all the functions in dev project before the import - literally comment out all the index.js, deploy it to dev, then import the json and then revert all the functions back for further investigation of any reported issues.

If there is a way to disable triggers in a more friendly way with the updated CLI I would much appreciate any input on how to achieve that. Otherwise removing functions from CLI in a batch is still something we rely on.