Firebase-tools: Развертывание функций очень медленное

Спасибо за подачу! Мы знаем, что медленное развертывание является серьезной проблемой для работы функций, и мы работаем над ее устранением с помощью различных стратегий.

@лауренцлонг
Как новичок в Firebase, на первый взгляд я подумал, что что-то напутал, потому что развертывание всегда останавливалось на части _functions: подготовка каталога функций для загрузки..._.
Предоставление дополнительной информации (например, выполнение занимает 3-5 минут) было бы очень приятно, пока проблема не будет решена.

Будучи новичком, я много раз отменял это, думая, что делаю что-то не так.

Проблема как бы очевидна. Команда init создала огромную папку «узловые модули». На моей машине это: 22 903 файла, 2 782 папки. Код копирует все это во временную папку.

Вот что я сделал:

1. Используя операторы печати журнала, я определил медленную строку кода. Это здесь:
   https://github.com/firebase/firebase-tools/blob/master/lib/prepareFunctionsUpload.js#L26

Строка 26 в prepareFunctionsUpload.js:
fs.copySync(options.config.path(options.config.get('functions.source')), tmpdir.name);

1. Я распечатал параметры для этого вызова копирования файла. На моей машине это:
   C:\Users\thoma\StudioProjects\LSystemAndroid\firestorefunctions
   -> C:\Users\thoma\AppData\Local\Temp\fbfn_752624vejX0cv3GEJI

Папка functions была создана командой CLI init. Это выглядит так:

• node_modules (огромный размер)
• .gitignore
• index.js
• пакет.json
• пакет-lock.json

Мне кажется, что команда CLI init НЕ должна была создавать эту папку node_modules. Это 165 МБ. Это кажется неразумным добавлять к каждому проекту.

@thomasfischersm

Дело не в этом. node_modules не копируется во временную папку, как видно из этой строки здесь: https://github.com/firebase/firebase-tools/blob/master/lib/prepareFunctionsUpload.js#L76 .

Необходимо для firebase init установить все модули узла локально внутри исходной папки функций, иначе локальное обслуживание функций не будет работать, и не будет работать извлечение триггера (именно так CLI понимает, какие события запускают каждый функция, чтобы он мог правильно их развернуть).

Я помещаю строку отладочной печати перед строкой 26 и после нее. Эта линия заняла минуты.

Затем я добавил фильтр, чтобы распечатать, какие файлы копируются. Он включал все файлы node_modules.

Затем я изменил фильтр, чтобы исключить файлы node_module. Развертывание теперь продвигалось быстро. Однако чуть позже показалось, что скрипт пытается оценить корректность облачных функций. Этот код не удался, потому что в нем отсутствовали зависимости библиотеки.

Строка исходного кода, на которую вы указываете, кажется, является более поздним шагом. Похоже, что файлы (за исключением node_modules) архивируются в zip-файл перед загрузкой в ​​облако. Эта строка, кажется, не работает медленно на моей машине.

Да, вы правы, я ошибся, node_modules действительно копируются. Я думаю, что это правильная идея не копировать node_modules во временный каталог. Что немного усложняет это, так это тот факт, что CLI записывает ".runtimeconfig.json" во временную папку перед синтаксическим анализом триггера, и этот файл загружается вместе с остальным исходным кодом функций, и мы не хотели писать этот файл в фактический каталог исходного кода. Так что, вероятно, есть хорошее решение, которое одновременно повышает скорость развертывания и гарантирует отсутствие непреднамеренных побочных эффектов, но мне придется немного поэкспериментировать. Вы также можете сделать запрос на вытягивание.

У меня такая же проблема. Может быть хорошей идеей напечатать больше сообщений во время шагов «подготовки каталога ...», чтобы пользователь не думал, что firebase-tools зависает.

Редактировать: это было на Ubuntu WSL. В Linux фаза «подготовки» не зависает. Этап «создание функции» может быть медленным, но не таким медленным, как раньше.

Эта проблема - настоящая боль в заднице. Я думаю, что это должно быть высшим приоритетом :/

Я пытаюсь внедрить функции firebase в свой проект, и из-за этой ошибки мне пришлось его отложить.
Эта ошибка заставила меня потратить много времени.
надеюсь скоро исправят!

Эта проблема является серьезным препятствием. В основном потому, что я использую firestore, и в таких вещах, как агрегаты, счетчики и присутствие, можно прилично обрабатывать только облачные функции, и каждый раз он просто зависает на 5 минут.

@PulpoEnPatineta Это не ошибка. Это просто проблема со временем развертывания.

@McStuffins Если ваш автомобиль заводится за пять минут, это ошибка или просто проблема со временем запуска?

Это можно как-то исправить? Это действительно очень медленно.

Я следил за этой проблемой с самого начала, но это никогда не было для меня проблемой, так как у меня есть настроенный компакт-диск, и он делает всю работу за меня. Я также никогда не развертываю функции только для того, чтобы проверить, работают ли они. Так что в принципе мне было все равно.

До сегодняшнего дня, когда я столкнулся с неожиданным ограничением: я больше не могу развертывать свои функции, потому что развертывание в рабочей среде превышает дневную квоту (12 000 секунд). У меня ~55 функций с разными триггерами (pubsub, firestore, https). Это слишком много, чтобы справиться?

Теперь мне нужно развернуть приложение на два дня :rofl: :lollipop: :+1: :1st_place_medal: :coffin: :tada: :taco: :cactus: :dancer: :smiling_imp:

Иногда, когда я развертываю, это происходит очень медленно, а затем в терминале появляется предупреждение «Ошибка в среде сборки».

@srinurp Пожалуйста, посмотрите запрос на вытягивание, на который я ссылался выше, он решит часть проблемы. А бэкэнд-команда работает над решением других частей проблемы (но это очень сложная задача, поэтому мы ценим ваше терпение).

@merlinnot Если вы не обновляете код для всех своих функций при каждом развертывании, я бы рекомендовал использовать команду --only для развертывания отдельных функций или групп функций. См . https://firebase.google.com/docs/cli/#partial_deploys.

@McStuffins «Ошибка в среде сборки» обычно указывает на производственную проблему, в этом случае отправьте запрос в службу поддержки по адресу https://firebase.google.com/support/ . Вы можете узнать, есть ли какие-либо текущие производственные проблемы, посетив Панель состояния Firebase

@laurenzlong Мне пришлось бы настроить свой CI для автоматического обнаружения изменений в каждой функции между развертываниями (включая разрешение зависимостей). А что, если я обновлю такие пакеты, как firebase-functions , firebase-admin , lodash и т. д., которые я использую в каждой отдельной функции?

@merlinnot Это очень законный вариант использования. Квоты на развертывание контролируются облачными функциями Google, я бы рекомендовал подать запрос на их общедоступный трекер проблем: https://cloud.google.com/functions/docs/support

Для всех желающих: https://issuetracker.google.com/issues/71385193

@laurenzlong Можно ли игнорировать папку node_modules при копировании источника, а затем делать npm install --production или yarn install --production ? Поскольку эти инструменты могут быть быстрее, чем простое копирование и вставка.

@horacehylee
Это может быть критическое изменение. Некоторые люди (в том числе и я) могут по-прежнему ссылаться на пакеты по относительному пути (например, «package-name»: «./externs/package.tgz»), в основном из-за ( теперь исправленной ) проблемы с частными репозиториями. Инструмент должен был бы учитывать все эти угловые случаи.

Другое дело — кеширование: если бы Google загружал пакеты от вашего имени, им пришлось бы внедрить какой-то внутренний механизм кеширования. У всех у нас есть локальные кэши на наших компьютерах (как npm, так и yarn имеют механизмы кэширования), поэтому мы не убиваем серверы npm ;)

Некоторые люди также могут захотеть просто протестировать некоторые изменения во внешних библиотеках. Гораздо проще просто изменить файл и развернуть функцию, чем создавать форк, вносить изменения, временно менять ссылку на пакет,...

Итог: работает отлично, оставь как есть :+1:

@horacehylee @merlinnot Спасибо за 2 цента. См. https://github.com/firebase/firebase-tools/pull/578 , следующий выпуск CLI больше не будет копировать период исходной папки функций.

Я действительно не уверен, что может делать firebase, который требует МИНУТ для развертывания 5-линейной функции 1 КБ на шестиъядерной машине с частотой 4 ГГц, подключенной к оптоволоконному соединению со скоростью 1 Гбит / с.

Я знаю, это звучит так, как будто я обижаюсь, но мне искренне любопытно, что происходит во время «подготовки каталога к загрузке». Кто-нибудь действительно знает?

Копирование вашего каталога функций, включая модули узла, в каталог tmp.

Наш следующий выпуск решит эту проблему, и вам больше не нужно копировать перед
развертывание.

В воскресенье, 7 января 2018 г., 17:05 [email protected] написал:

Я действительно не уверен, что firebase может делать, что занимает МИНУТЫ, чтобы
разверните 5-линейную функцию 1 КБ на шестиъядерной машине с частотой 4 ГГц, сидящей на
Оптоволоконное соединение 1 Гбит/с.

Я знаю, это звучит так, как будто я придираюсь, но мне действительно любопытно, что
происходит во время «подготовки каталога к загрузке». Кто-нибудь действительно знает?

—
Вы получаете это, потому что подписаны на эту тему.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/firebase/firebase-tools/issues/536#issuecomment-355868154 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AAAD_nUptJWFuYGvEXI0MwmQR-bG9_MKks5tIWm1gaJpZM4QdF3g
.

@mbleigh

Ах да. что объясняет его. Это своего рода комедия, когда рабочая станция сходит с ума на минуту или две только для того, чтобы следующая строка распечатала «упакованные функции ( 37,55 КБ !!!) успешно для загрузки», лол.

С нетерпением ждем следующего выпуска. Спасибо за ответ.

ЧАС.

День 19. Firebase все еще развертывается. *хватает попкорн*

Да.

Когда запланирован следующий релиз и на какое процентное сокращение времени развертывания нам следует рассчитывать?

Просто чтобы знать, стоит ли продолжать идти по этому пути.

Релиз должен состояться на этой неделе, и вы можете ожидать «Подготовка
каталог функций для развертывания», чтобы выполнить шаг значительно быстрее (я не
есть точные цифры). Другие части развертывания останутся без изменений.

В понедельник, 15 января 2018 г., в 12:42 [email protected] написал:

Да.

Когда планируется следующий релиз и какой % улучшения в развертывании
раз мы должны ожидать?

Просто чтобы знать, стоит ли продолжать идти по этому пути.

—
Вы получаете это, потому что вас упомянули.

Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/firebase/firebase-tools/issues/536#issuecomment-357784792 ,
или заглушить тему
https://github.com/notifications/unsubscribe-auth/AAAD_vaj-WngS9dMj7j5Q2AesM0tNMvVks5tK7hBgaJpZM4QdF3g
.

Это было выпущено!

@mbleigh Это в версии 3.17.4?

@jkossis v3.17.0

Из примечаний к выпуску:

Если вы развертываете функции, вы должны обновить SDK firebase-functions до последней версии, запустив «npm i --save firebase -functions@latest » внутри вашего каталога функций. Это обеспечивает более быстрое развертывание функций.

от минут до секунд: молодец!

Для меня это все еще занимает минуты.

У меня есть [email protected] и [email protected] . Что я могу сделать, чтобы помочь в дальнейшей отладке этой проблемы?

Вот синхронизированный результат развертывания только функций. Я изменил имена, но они представляют собой комбинацию конечных точек REST, базы данных и триггеров аутентификации.

➜  functions git:(master) ✗ firebase --version
3.17.4
➜  functions git:(master) ✗ time firebase deploy --only functions

=== Deploying to 'XXX'...

i  deploying functions
i  functions: ensuring necessary APIs are enabled...
✔  functions: all necessary APIs are enabled
i  functions: preparing functions directory for uploading...
i  functions: packaged functions (123.07 KB) for uploading
✔  functions: functions folder uploaded successfully
i  functions: updating function 1...
i  functions: updating function 2...
i  functions: updating function 3...
i  functions: updating function 4...
i  functions: updating function 5...
i  functions: updating function 6...
✔  functions[1]: Successful update operation.
Function URL (1): https://us-central1-XXX.cloudfunctions.net/1
✔  functions[3]: Successful update operation.
✔  functions[4]: Successful update operation.
✔  functions[5]: Successful update operation.
✔  functions[6]: Successful update operation.
✔  functions[2]: Successful update operation.
Function URL (2): https://us-central1-XXX.cloudfunctions.net/2

✔  Deploy complete!

Project Console: https://console.firebase.google.com/project/XXX/overview
firebase deploy --only functions  4.59s user 1.07s system 1% cpu 6:09.26 total

@adamduren исправление было связано с чрезмерным временем, проведенным в preparing functions directory for uploading...

Сами развертывания могут занять довольно много времени.

стек в той же ситуации:

"firebase-admin": "^5.8.2",
"firebase-functions": "^0.8.1",

npm install -g npm@latest дал мне немного другой ввод, и удаление firebase-cli , похоже, тоже что-то изменило.

Обновить:

хорошо, после запуска npm install -g firebase-tools это наконец сработало. Престижность https://stackoverflow.com/questions/48531993/firebase-config-variables-are-not-available-error-with-deploying-functions#comment84098334_48531993

Привет, у меня проблема в том же месте ("подготовка каталога функций...")
но в моем случае это заняло более 25/30 минут
У меня есть 4 частные зависимости, которые весят сжато около 2,20 МБ.
Я обнаружил, что это единственный способ включить частные зависимости в виде сжатых файлов.
Я делаю что-то неправильно? или это способ должен работать?

2018-5-9
firebase deploy все еще медленно, не знаю почему

Вы обновились до последней версии? Я обновился на прошлой неделе, и теперь мой деплой занимает 1-3 минуты (с 25/30).

Я вижу время развертывания более 4 минут для чего-то простого, например:

const functions = require('firebase-functions')

exports.test = functions.https.onRequest((req, res) => {
  res.send('Hello World')
})

i functions: updating function test... — это строка, которая висит.
Никогда раньше не было так медленно!

@Robula Вы обновились до последней версии firebase-tools?

Да, я так думаю. firebase —version отчеты 3.18.6.

у вас более поздняя версия, чем у меня. Я не уверен, возможно, они продолжили перенос папки node_modules снова в 3.18.6, но на данный момент с 3.18.4 все работает нормально...

В последних версиях firebase-tools не было регресса в стратегии развертывания (папка node_modules не копируется), однако время развертывания также меняется от машины к машине и время от времени. Первоначальное развертывание функции также происходит медленнее, чем последующие обновления.

Я вижу, что время развертывания на этапе preparing functions directory for uploading... занимает почти 7 минут только на этом этапе при локальном запуске. Шаг предварительного развертывания для сборки локально занимает около 5 секунд. Все остальные шаги в процессе развертывания запускаются из отладки очень быстро. Я понимаю, что развертывание может быть несколько медленным, но я также использую AWS lambda для работы, и развертывание очень больших лямбда-выражений выполняется намного быстрее, порядка 2–2 3 минут, включая установку и сборку пакетов Python.

Даже развертывание из облачной сборки Google занимает от 2 до 3 минут по сравнению с 10–20 секундами в aws lambda. Я просто хочу спросить, архивирует ли cli всю папку функций перед загрузкой?

@laurenzlong , не могли бы вы уточнить, развернуты ли функции уже параллельно или эта оптимизация находится в разработке?

Функции всегда развертывались параллельно. Однако обратите внимание, что параллельное развертывание 10 функций все же медленнее, чем развертывание одной функции.

+1 То, что развертывание функции происходит очень медленно. Я следовал учебному пособию по cron для создания функции почасового тика, моего самого первого тона, и каждый раз развертывание занимает около минуты.

@laurenzlong большое спасибо за ответ и спасибо за вашу усердную работу над Firebase!

Есть ли какие-либо активные планы по сокращению времени развертывания? Я спрашиваю, потому что, хотя нам нравится Firebase, мы на самом деле думаем отказаться от него из-за медленного развертывания. У нас есть около 47 облачных функций, и их развертывание обычно занимает 3–6 минут. Сравните это с git push heroku master , для развертывания того же объема кода в Heroku потребуется около 20-30 секунд. И тогда этот код мгновенно запустится на Heroku. С Firebase нам нужно подождать еще 20-30 секунд (случайно) после развертывания, прежде чем развернутые функции будут фактически запущены (в это время запускаются как новые, так и старые функции).

Итак, сравните опыт развертывания:

*** Heroku:

git push heroku master

20-30s later ...

All newly-deployed functions are now running in a consistent/atomic way

*** Firebase:

firebase deploy --only functions

180-360s later ...

Functions are deployed but only some of the new ones are running, some old ones are still running

20-30s later ... 

All new functions running

Также сложно выполнить атомарное развертывание с помощью Firebase, потому что после развертывания есть период времени, в течение которого некоторые из новых функций, назовем их v_n+1 , работают вместе с некоторыми из старых функций v_n . Таким образом, если вы делаете серьезное обновление, у вас будет сочетание новых и старых функций, работающих, возможно, с использованием разных форматов данных или алгоритмов. Это гораздо менее безопасно, чем развертывание Heroku, где либо развертываются все новые функции, и только новые функции выполняются, либо не развертываются никакие.

Кроме того, иногда некоторые из наших 47 функций не могут быть развернуты с такими ошибками, как

⚠  functions[retrieveFavorites(us-central1)]: Deployment error.
Server Error. getaddrinfo ENOTFOUND cloudfunctions.googleapis.com cloudfunctions.googleapis.com:443

Мы развертываем высоконадежный симметричный гигабитный Интернет, поэтому проблема не в нашей сети.

Так что думайте о развертывании Heroku как об атомной транзакции БД (все или ничего), тогда как развертывание Firebase больше похоже на в конечном итоге совместимое с частичными сбоями ... Это значительно усложняет разработку, особенно если вы исправите ошибку в посреди ночи в ответ на страницу.

Честно говоря, опыт развертывания на Firebase объективно медленнее и менее надежен, чем на Heroku или AWS... Не поймите меня неправильно, нам нравится Firebase, и мы действительно ценим всю вашу тяжелую работу. Я не хочу, чтобы это звучало как атака, в этом нет ничего личного, но нам нужно, чтобы Firebase работал лучше здесь, или мы думаем о переходе в другое место, потому что развертывание слишком болезненно.

Еще раз спасибо за вашу усердную работу над Firebase. Мы ценим вашу помощь :-).

Спасибо, что поделились своей точкой данных! У нас есть некоторые планы по улучшению этого, особенно для одновременного развертывания многих функций (в основном улучшение этапа сборки на стороне сервера после выполнения вызова API для создания/обновления функции). Тем не менее, это изменения инфраструктуры, которые потребуют кварталов, поэтому мы очень ценим ваше терпение.

Возможно, вы уже подумали об этом, но вы можете создать сценарий в конвейере CI/CD, который определяет, какие функции были отредактированы, и развертывать только те из них, у которых установлен флаг --only . Это значительно улучшит скорость развертывания. Посмотрите это видео для примера: https://www.youtube.com/watch?v=iyGHW4UQ_Ts

@laurenzlong Спасибо за информацию, Лорен. Однако у меня есть только одна небольшая облачная функция, и ее развертывание занимает около 1 минуты даже после внесения минимальных изменений. Я также использую этот флаг, хотя у меня есть только одна облачная функция. Кажется, здесь что-то не так.

По состоянию на апрель 2019 года все еще занимает буквально минуты - версия Firebase 6.6.0 - все, что я делаю, это следую инструкциям здесь: https://firebase.google.com/docs/functions/get-started

Только что скачал и занимает несколько минут каждый раз, когда я "разворачиваю firebase"

В последние пару дней развертывание даже хостинга занимает несколько минут, тогда как пару недель назад это занимало 10-15 секунд. Время развертывания функций также истекает.

А страница статуса Firebase зеленая https://status.firebase.google.com/ .

кто-нибудь знает, почему это произошло?

Использование firebase-tools 7.0.0

$ firebase deploy --only=hosting --token xxx

=== Deploying to 'xxx'...

i  deploying hosting
i  hosting[xxx]: beginning deploy...
i  hosting[xxx]: found 1959 files in public
✔  hosting[xxx]: file upload complete
i  hosting[xxx]: finalizing version...
✔  hosting[xxx]: version finalized
i  hosting[xxx]: releasing new version...
✔  hosting[xxx]: release complete
✔  hosting: Finished running postdeploy script.

✔  Deploy complete!

Project Console: https://console.firebase.google.com/project/xxx/overview
Hosting URL: https://xxx.firebaseapp.com
✨  Done in 181.75s

@laurenzlong-

Тем не менее, это изменения инфраструктуры, которые потребуют кварталов, поэтому мы очень ценим ваше терпение.

Какие-нибудь обновления инфраструктуры со времени вашей последней заметки несколько кварталов назад? Пока эти изменения не внесены, возможно ли повторно открыть этот вопрос? Закрытое не кажется подходящим состоянием, если только отслеживание не перешло к другой/связанной проблеме.

Firebase functions по-прежнему работает очень медленно после того, как все было создано/загружено, а функции создаются/обновляются на стороне сервера. Как уже говорили другие, это главный демпфер скорости разработки.

firebase --version
7.1.0

Большое спасибо за рассмотрение!

@repentsinner серверный проект по сокращению времени сборки/развертывания все еще продолжается (и идет хорошо!), но он еще не выпущен.

Пробовали ли вы использовать эмулятор (через firebase emulators:start ) для ускорения процесса разработки? Если это так, мы будем рады получить ваш отзыв!

Спасибо за обновление @samttern.

Я еще не пробовал эмулятор - я использую functions.https.onCall из флаттер-приложения, а также данные из firestore, и кажется (во всяком случае, на данный момент) перенаправление всего в тестовых сборках приложения для моей рабочей станции разработки требует больше усилий, чем ожидание развертывания.

Я думаю, я могу использовать время, которое я жду, чтобы изучить это 🤨.

Поздравляем с Новым годом эту проблему, которая до сих пор закрыта и до сих пор не исправлена! 🎉

Возможно, администратор или ОП может переименовать эту проблему в «Подготовка каталога функций к чрезвычайно медленному развертыванию», поскольку, похоже, она была закрыта исключительно на основе исправления этого этапа общего процесса развертывания.

Затем мы можем открыть новую проблему «Очень медленное развертывание функций», поскольку ... развертывание функций по-прежнему происходит очень медленно 😄

Эта проблема была закрыта, потому что мы больше ничего не можем сделать на стороне командной строки, чтобы сократить время развертывания. Для локальной разработки мы продолжаем инвестировать в эмулятор, мы надеемся, что людям придется запускать firebase deploy только при развертывании в рабочей среде, а не в рамках жизненного цикла разработки.

Изменения в бэкенде все еще продолжаются. Как вы понимаете, были неожиданные задержки.

Спасибо за разъяснение @samtstern , так что я предполагаю, что вопросы/запросы к firebase/firebase-tools применимы только к CLI? Буду искать репозиторий/проект, охватывающий серверную часть.

Что касается локальной разработки, то со стороны общественности кажется, что Google действительно поощряет интеграцию Firebase и Flutter, которые на первый взгляд очень хорошо работают вместе, но на практике мы сталкиваемся с такими несоответствиями во время разработки, как это. Я быстро взглянул на эмулятор, как было предложено при обнаружении этой проблемы, но на самом деле он вообще не поддерживал интегрированный рабочий процесс разработки Firebase плюс Flutter, конечно, не так гладко, как через облачную серверную часть. Я не возвращался назад, чтобы посмотреть, улучшилось ли это в последнее время, но это кажется маловероятным.

@repentsinner да, это репо отслеживает только работу CLI. Конечно, мы пытаемся ответить на все, что приходит, но часто нам приходится закрывать вопросы, когда мы не можем сделать здесь ничего продуктивного. Наши серверные части не имеют открытого исходного кода, поэтому мы обычно отправляем людей в службу поддержки Firebase, чтобы отправлять отчеты об ошибках или запросы на добавление функций в отношении общих вещей Firebase.

Что касается Flutter, нам он нравится (см.: https://github.com/FirebaseExtended/flutterfire), но важно отметить, что это не официальная платформа Firebase, а это означает, что мы не можем предложить полную поддержку по вопросам, как мы делаем на нативный Android/iOS/Web. Может быть, когда-нибудь это изменится, но пока ситуация такая.

Если у вас есть вопросы о том, как подключить ваше приложение Flutter к эмуляторам Firebase, откройте вопрос в репозитории FlutterFire и скопируйте меня, тогда я также смогу привлечь нужных людей Flutter.

Понял, спасибо за разъяснение @samtstern! На данный момент я перешел к другим проектам, но посмотрю репозиторий FlutterFire, когда вернусь к этим вещам.

Эмулятор не поддерживает контекст аутентификации, поэтому он на 100% совершенно бесполезен, IMO.

В конце концов я обнаружил, что мои развертывания зависли, потому что я пытался использовать dotenv.

Просто заглядываю, чтобы напомнить людям, что это все еще болевая точка ✌️

Для людей, которые все еще сталкиваются с этим - одна вещь, которую я нашел полезной, это использование functions.ignore , чтобы избежать загрузки ненужного раздувания. Я думаю, что особенно хорошо включить .git :
{ "functions": { "ignore": ["node_modules", ".git", ".gitignore", ".nyc_output", ".runtimeconfig.json", "firebase-debug.log", "tslint.json", "tests"] }

Я полностью отказался от функций, так как рабочий процесс разработки более чем болезненный.

Для людей, которые все еще сталкиваются с этим - одна вещь, которую я нашел полезной, это использование functions.ignore , чтобы избежать загрузки ненужного раздувания. Я думаю, что особенно хорошо включить .git :

"functions": {
    "ignore": ["node_modules", ".git", ".gitignore", ".nyc_output", ".runtimeconfig.json", "firebase-debug.log", "tslint.json", "tests"]
  }

Это действительно дало определенные результаты. Работает примерно 65-70% времени. Спасибо!

Интересно - по умолчанию подкаталог functions находится под корнем проекта, поэтому в нем не будет папки .git . Люди, которым это помогло - как выглядит ваша структура каталогов?

@mbleigh Верно. Я думаю, что это разумно и применяет их к каталогу функций.

@mbleigh У меня есть репозиторий только для функций, поэтому было немного глупо иметь каталог функций. Все сместилось в корень.

Это выдержка из моего firebase.json :

  "functions": {
    "ignore": [
      "__mocks__",
      ".cache",
      ".commitlintrc.yaml",
      ".dependabot",
      ".editorconfig",
      ".eslintrc.yaml",
      ".firebase",
      ".firebaserc",
      ".git",
      ".gitattributes",
      ".github",
      ".gitignore",
      ".lintstagedrc.js",
      ".nvmrc",
      ".prettierignore",
      ".prettierrc.yaml",
      ".vscode",
      "CHANGELOG.md",
      "cloudbuild.yaml",
      "codecov.yml",
      "CONTRIBUTING.md",
      "coverage",
      "cSpell.json",
      "decisions",
      "firebase.json",
      "firestore.indexes.json",
      "jest.config.js",
      "node_modules",
      "README.md",
      "rfcs",
      "scripts",
      "src",
      "test",
      "tsconfig.json",
      "tsconfig.production.json"
    ],
    "source": "."
  },

Я бы с удовольствием заменил его на:
```
{
"include": ["lib", "package.json", "package-lock.json"]
}

FWIW Я считаю, что они принимают globs, поэтому вы можете сделать:

{
  "exclude": ["!{lib,package.json,package-lock.json}"]
}

Только что запустил облачные функции, и время развертывания мучительно.

болезненное время развертывания :(

В нашем приложении Firebase сейчас запущено 60 облачных функций. Сначала у нас было много сбоев развертывания из-за квот, поэтому мы разбили его на пакеты, как предлагает документация. Теперь он последовательно развертывается, но развертывание каждого пакета занимает около 3 минут в рамках CI действий GitHub на исполнителях по умолчанию. Пакетов около 6, поэтому всего 10 пакетов, что делает время развертывания нашей функции около 30 минут.

Сами функции представляют собой очень маленькие фрагменты кода с минимальными зависимостями. Не уверен, что еще мы можем сделать, чтобы ускорить конвейер.

Это очень грустно слышать. Другой подход заключается в объединении нескольких точек входа/маршрутов в одну функцию. Очевидно, что это не лучший вариант из-за разделения задач/размера/безопасности, но это то, что мы сделали со всеми нашими конечными точками API (единая точка входа, которая затем использует внутренний маршрутизатор), и с тех пор не сталкивались со многими ограничениями квот (но иногда они случаются).

Тем не менее, этот предел квоты кажется очень низким, поскольку в официальном документе указано «80 за 100 секунд» для «Вызовов для развертывания или удаления функций через API облачных функций». Я предполагаю, что служба поддержки Google не может поднять этот предел еще больше?

Тем не менее, этот предел квоты кажется очень низким, поскольку в официальном документе указано «80 за 100 секунд» для «Вызовов для развертывания или удаления функций через API облачных функций». Я предполагаю, что служба поддержки Google не может поднять этот предел еще больше?

@dinvlad Я спрашивал как в отделе продаж, так и в службе поддержки об увеличении этого лимита API, он явно отключен / выделен серым цветом в разделе квот консоли GCP. В конце концов мне удалось найти инженера Google по видеовстречам, который сообщил мне: «Эта квота не меняется»... так что я думаю, что нет.

Мы добавили .git в стандартный список игнорирования в следующем релизе:
https://github.com/firebase/firebase-tools/pull/2395

Это должно ускорить релизы для некоторых. Конечно, мы (команда Firebase CLI) мало что можем сделать с задержкой в ​​бэкэнде Cloud Functions.

обязательно делайте firebase deploy --only hosting , когда вы не обновляете функции

Здесь мы также сгруппировали связанные функции в функции, поэтому в итоге это выглядит как «одна функция на область функций», а не «одна функция на отдельную гранулу функциональности».

Характеристики производительности развертывания сильно влияют на архитектуру того, что входит в одну функцию!

Когда и почему этот вопрос был закрыт. Он был открыт в ноябре 2017 года, и похоже, что это все еще такая же проблема, как и тогда. Я не вижу здесь ссылки на «Закрыто», и мне было бы интересно узнать, почему оно было закрыто.

Я не жалуюсь, просто интересно. Я уверен, что над этим работают, но было бы неплохо узнать о каком-либо прогрессе.

@chriscurnow он был закрыт, потому что настоящая причина, по-видимому, связана с серверной стороной (с закрытым исходным кодом), а не с инструментами CLI, хотя для конечных пользователей это проявляется как проблема CLI (согласно @samtstern в https://github.com /firebase/firebase-tools/issues/536#issuecomment-572830647).

К сожалению, для серверной части нет хорошего общедоступного трекера, поэтому мы получаем обновления здесь :(

Как мы можем открыть эту ошибку для Google, чтобы исправить ее в своем бэкэнде?
Это смехотворно медленно

Мол, какой вообще смысл использовать функции firebase, если это займет так много времени

Эй, ребята, может быть, мы все могли бы сообщить об этой проблеме в Google, и, может быть, они прислушаются?
https://firebase.google.com/support/troubleshooter/contact

Каждый раз, когда я пытаюсь использовать что-то из Google для чего-то важного, мне напоминают, что это одна из наименее дружественных к потребителю существующих компаний, но, эй, мы могли бы попробовать.

@RenFontes Я только что подал дело 00075974: развертывание функций Firebase настолько медленное, что его невозможно использовать с поддержкой Firebase. Я обновлю это сообщение тем, с чем они вернутся.

Можно развернуть определенные функции. Разве CLI не может иметь «трекер контрольных сумм» для каждой функции и развертывать только измененные (а также отслеживать все, что он использует: vars, пакеты, ...)?

@SrBrahma конечно, но проблема все еще присутствует, даже если вы развертываете только одну функцию (например, развертывание одной функции может завершиться ошибкой из-за тайм-аута).

На пользователя не должно возлагаться управление развертыванием функций пакетной обработки, и во многих случаях обновления функций необходимы атомарно, поэтому их нельзя разделить/пакетировать.

Ценим предложения по обходному пути, но на самом деле нам здесь нужно SLA от Google и их соблюдение.

Это правда, что Firebase иногда работает? это намного быстрее, чем Node?

Все еще ждете, пока Google улучшит время развертывания функций Google, верно?
Переход с PWA на SSR заставил меня ждать на 7 минут больше для каждого развертывания 😞