Firebase-tools: اقبل ملف JSON للوظائف: config: set

أتفق مع jpreynat ، نحن التكوين: سيكون التعيين في نصوص النشر المخصصة الخاصة بنا باستخدام config.json ميزة رائعة لرؤية الإضافات.
هل هناك أي حلول في الوقت الحالي ، ربما الأنابيب في التكوين؟

يبدو أنك تحاول تكرار التكوين عبر المشاريع. هل سيعمل firebase functions:config:clone أجلك؟

لإعطاء بعض السياق ، ابتعدنا عن قصد عن التكوين المستند إلى الملفات لأننا نعتقد أنه يشجع الممارسات السيئة (أي الاحتفاظ بملف مليء بالأسرار المخزنة مع الكود الخاص بك ، ومن المحتمل أن يتم تسجيله في مستودع المصدر الخاص بك).

ما رأيك في طريقة ما (الميكانيكا TBD) للإعلان عن متغيرات التكوين "المطلوبة" - وإذا حاولت النشر بدون التكوين المطلوب في المشروع الحالي ، فسوف يحدث خطأ قبل تغيير أي شيء. هل سيحل ذلك مخاوفك الرئيسية؟ إذا لم يكن الأمر كذلك ، فلماذا يكون وجود ملف مفيدًا لك تحديدًا؟

mbleigh هذا بالضبط ما لم أكن أعرفه
من المحتمل أن يكون معطى / ما قصدته بـ "ميكانيكا TBD" ، ولكن: تحديد بنية المفاتيح / التكوين في بعض الملفات داخل مشروعنا وليس عن بُعد ، بحيث يمر بعملية مراجعة git / PR مثل أي شيء آخر.
jpreynat آسف لقضية الاختطاف

@ laurenzlong شكرًا على النصيحة ، لكننا لا نحاول تكرار ملف التكوين.
شاغلنا الرئيسي هو تحديث تكوين المشاريع المختلفة اعتمادًا على مرحلة النشر لدينا.
لذلك بشكل أساسي ، لدينا ملف تكوين لكل بيئة (dev و staging و prod) ، وقمنا بتعيين تهيئة Firebase على التوالي (بالنسبة إلى العلاقات العامة ، اضغط على المفتاح الرئيسي والعلامات).

mbleigh شكرا على المعلومات.
ومع ذلك ، لسنا متأكدين تمامًا من كيفية تخزين كل هذه العناصر بطريقة أخرى غير استخدام ملفات التكوين.
تم تنسيقها حاليًا كـ JSON لقراءة البساطة ، لكننا نفكر في تنسيقها كأزواج مفتاح / قيمة لتمريرها مباشرة إلى الأمر functions:config:set .
أنا أتفق معك في أن هذا ليس أكثر أمانًا من تمرير ملف JSON.
هل لديك أي توصيات حول كيفية تخزين متغيرات بيئتنا لمراحل مختلفة بخلاف استخدام الملفات؟

ahaverty لا تقلق ، أنا سعيد لأن هذا يمكن مناقشته هنا.

jpreynat عند تشغيل functions:config:set يتم تخزينه مع المشروع الحالي. إذا كنت تستخدم firebase use للتبديل بين المشاريع ، فسيظل التكوين الخاص بك ثابتًا. لذلك يمكنك تشغيل set مرة واحدة لكل مشروع وبعد ذلك سيكون هناك دائمًا . يجب أن يحل هذا مشكلة "التكوين المختلف للبيئات المختلفة" ، لذلك ربما لا أفهم المشكلة الحقيقية؟

jpreynat سأغلق هذه المشكلة في الوقت الحالي ، ولكن يُرجى إعادة فتحها إذا

laurenzlongmbleigh عذرا أن لم أكن الإجابة بسرعة على هذا الموضوع.
لقد توصلنا إلى حل بديل لهذه المشكلة في الوقت الحالي ، ولكن إليك بعض السياق لتوضيح طلبي:

نحن ننشر تطبيقنا باستخدام Travis (لاحظ أن هذا سيكون رائعًا مع أي CI أو حتى محليًا). نظرًا لأننا ننشر تطبيقنا في مراحل مختلفة اعتمادًا على الفرع والعلامة ، فسيكون من الرائع أن نتمكن من استخدام ملف JSON مختلف بناءً على البيئة.
على سبيل المثال ، سيسمح هذا بإجراء إما firebase config:set -f staging.json أو firebase config:set -f prod.json اعتمادًا على هذه الحالة.
كان الحل البديل لدينا هو استخدام firebase كوحدة عقدة ، ولكن لا يزال يتعين علينا تضمين تكوين JSON الخاص بنا ، والذي يكون عرضة للأخطاء.

مرحبًا jpreynat ما زلت مرتبكًا بعض الشيء من إجابتك. بمجرد تعيين التكوين مرة واحدة ، فإنه يظل دائمًا هناك ، حتى عبر عمليات النشر ، ما لم تقم صراحة بإلغاء تعيين قيم التكوين عن طريق تشغيل وظائف firebase

هل يمكن لشخص ما إعادة فتح هذا؟ ٪)jpreynatmbleigh هذا حقا واحدة من الأشياء التي مفقود. لدى Atm ما يقرب من 15 متغيرًا للتكوين (والمزيد قادم) وسيكون ذلك مفيدًا جدًا إذا كان functions:config:set يمكنه قبول JSON بطريقة ما.

تصويت كبير منا لاقتراح mbleigh على "إعلان" متغيرات التكوين "مطلوب" - وإذا حاولت
أن تصبح نقطة ألم بالنسبة لنا أيضًا ، ولكن هذا من شأنه أن يحل جميع مشكلاتنا وسوف يتناسب بشكل جيد مع عملية التحكم / المراجعة في الإصدار 👍

https://medium.com/@AllanHasegawa/setting -config-for-firebase-cloud-function-with-json-136f455e7c69

مرحبًا yaronyosef يمكنك توفير JSON مباشرة : config : الأمر set ، كل ما عليك هو تنسيقه بطريقة تناسب نظامك الأساسي. بالنسبة إلى Linux ، يجب أن يعمل ما يلي:

firebase functions:config:set foo='{"bar":"something","faz":"other"}'

شكرا لك على مشاركتك! تضمين التغريدة
كنت أرغب في الاستيراد من ملف ، لذلك استخدمت أمرًا مثل هذا.

firebase functions:config:set service_account="$(cat service-account.json)"

لقد قمت باستيراد ملف json لحساب الخدمة إلى Firebase Cloud Functions ، لأنني أردت استخدام واجهة برمجة تطبيقات إدارة المستخدم الخاصة بـ Firebase Admin SDK.

حالة استخدام رائعة! شكرا للمشاركة!

نفضل أيضًا تتبع التكوينات غير السرية من خلال Git ، حيث ستكون ملفات تكوين وقت تشغيل JSON (لبيئات متعددة) موثوقة وستقوم بيئة CI بعد ذلك بتطبيق functions:config:set من الملف المقابل لبيئة معينة (و تتوافق كل بيئة مع مشروع Firebase منفصل).

إذا احتفظت بالتكوينات في git ، فمن السهل قراءتها في وقت تشغيل الوظائف. فقط ضعهم على configs/<project_id>.json ثم:

let config = {};
try {
  config = require(`./configs/${process.env.GCLOUD_PROJECT}.json`);
} catch (e) {
  console.log('No config found for project', process.env.GCLOUD_PROJECT);
}

تم تصميم تهيئة وقت التشغيل التي يستخدمها Firebase خصيصًا لتجنب تسجيل التكوين في git ، حيث وجدنا (خاصة مع الأسرار) أنه نمط يسبب مشاكل أكثر مما يحلها.

هذا صحيح ، على الرغم من أننا لم نعد نستخدم Config API لهذا الغرض على الإطلاق. قد يكون من المفيد الاستمرار في استخدام Config API لتخزين القيم الحساسة (والتي تبدو أنها حالة استخدام مناسبة ، استنادًا إلى مستندات Firebase) وتحميل كل من القيم التي يتحكم فيها المصدر وغير المتتبعة بنفس الطريقة بالضبط (أي من خلال config() مقدم من firebase-functions ).

في الوقت الحالي ، أستخدم السطر الواحد التالي لإطعام .runtimeconfig بالكامل إلى functions:config:set :

firebase functions:config:set $(jq -r 'to_entries[] | [.key, (.value | tojson)] | join("=")' < .runtimeconfig/${FIREBASE_ENV}.json)

حيث FIREBASE_ENV هو اسم البيئة المستخدمة في النشر (مثل dev ). سيكون من الجيد أن تكون قادرًا على تقصير هذا أكثر ، على سبيل المثال

firebase functions:config:set -f .runtimeconfig/${FIREBASE_ENV}.json

في النهاية ، قد لا يكون ذلك ضروريًا إذا قام Config API بتمكين مسارات تدقيق سهلة الاستخدام لجميع التغييرات (يرجى تصحيحها إذا كان هذا هو الحال بالفعل ، أود استكشاف ذلك).

فكيف يأتي هذا؟ 😄

أحب أن أرى اقتراح mbleigh قيد التنفيذ! نواجه باستمرار مشكلات في نسيان تعيين التكوينات على أهدافنا غير المطورة

شكرا لنتوء الخيط. لا يوجد شيء للإبلاغ عنه حتى الآن ، لكنني سأطرح هذا الأمر مرة أخرى في اجتماعات التخطيط لدينا لمعرفة ما إذا كان بإمكاننا البدء في إحراز بعض التقدم في هذا الشأن.

أتحقق من صحة التهيئة باستخدام ملف مخطط JSON للتأكد من احتوائه على جميع القيم التي أتوقعها. هذا التحقق من الصحة هو جزء من خط أنابيب CI الخاص بي ويمنع النشر إذا فشل. إذا كنت تستخدم TypeScript مثلي لكتابة وظائفك ، فيمكنك إنشاء مخطط JSON من الأنواع الخاصة بك.

إنه يعمل بشكل رائع ، مع وجود قيود على أن الوظائف config تقبل فقط السلاسل ، لذلك لا يمكن للمخطط التحقق من أن قيمة التكوين هي رقم. بالنسبة إلى القيم المنطقية ، لا بأس بذلك لأنه يمكنني استخدام تعداد مع "true" و "false" كقيم صالحة فقط.

راجع تهيئة CircleCI الخاصة بي ومنشور المدونة هذا للرجوع إليه.

hgwood شكرا للمشاركة! سنقوم بالتأكيد بإضافة هذا إلى CI الخاص بنا أيضًا.

أردت فقط ترك حل لهذه "المشكلة" ، وأفكاري حول المناقشة:

1. أفهم أنه لا ينبغي تخزين القيم السرية / الحساسة في الريبو. الحل الخاص بي هو فقط للقيم غير السرية. يتم تعيين القيم السرية يدويًا ، ولكن طريقة لتمييز قيم التكوين على النحو المطلوب ستكون رائعة لتلك القيم السرية.
2. أعتقد أن هذا أكثر أهمية مما يعتقده البعض. يجب على PITA تعيين قيم التكوين الفردية يدويًا لمشاريع بيئة النشر المختلفة ، وعدم القدرة على عرضها / مقارنتها في نفس الوقت بسهولة. تحديد التكوينات في الملفات يجعل العملية أقل صعوبة.
3. أعتقد أن إضافة محرر تكوين وظائف إلى وحدة تحكم الويب سيؤدي إلى تحسين هذا كثيرًا ، ولكن سيكون من الرائع حقًا إذا كانت هناك طريقة لعرض التكوينات لمشروعات متعددة في نفس الوقت ، بحيث يمكنك بسهولة مقارنة التكوينات لبيئات النشر المختلفة.
4. لقد كنت أقول إلى الأبد أن Firebase يحتاج إلى السماح بتحديد البيئات ضمن مشروع واحد ، لذلك لا تحتاج إلى مشاريع متعددة لاستخدامها كبيئات نشر. إذا كان هذا موجودًا ، فسيكون من السهل جدًا عرض التكوينات لبيئات متعددة في نفس الوقت في مشروع واحد.
5. ربما يحتوي الحل الخاص بي على مشكلات ، فلا تثق في الكود الخاص بي حرفيًا ، لكني أحب المفهوم العام.

بلدي الحل

أستخدم ملفات تكوين yaml المتتالية ، وهي مفيدة للقيم والقيم الافتراضية التي تنطبق على جميع التكوينات بغض النظر عن بيئة النشر.

./config/default.yml

app:
  name: My App
featureFlags:
  someFeature:
    enabled: false

./config/dev.yml (ملفات تهيئة مماثلة لبيئات النشر الأخرى)

imports:
  - {resource: default.yml}
app:
  environmentName: Development
services:
  someOtherService:
    baseUrl: https://dev.someotherservice.com/api
featureFlags:
  someFeature:
    enabled: true

بعد ذلك ، قمت بكتابة برنامج نصي صغير للعقدة يقوم بتحميل التكوين الذي تم حله ، ويعيد قائمة محددة بمسافات من أزواج key = val

yaml_to_keyval.ts

import * as configYaml from "config-yaml"
import * as flat from "flat"


const yamlFile = process.argv[2]
const config = configYaml(yamlFile)
const flatConfig = flat(config)

const key_val_list = Object.keys(flatConfig).map(function(key){
    return `${key}=${flatConfig[key]}`
})

console.log(key_val_list.join(' '))

أثناء نشر CI ، أستخدم برنامج bash shell هذا للحصول على أزواج key = val وتعيينها بالوظائف: config : set

# env is set to the desired deployment environment (eg "dev"), which is passed as an argument to the CI script command
config_in="$(readlink -f ./config/$env.yml)"
key_vals="$(ts-node ./scripts/node/yaml_to_keyval.ts $config_in)"
firebase functions:config:set $key_vals

kanemotos يعجبني حل cat ، لكن ألم تصادف خطأ Precondition check failed عند محاولة تحميل ملف cert الخاص بك؟

انتهى بنا الأمر باستخدام Deployment Manager لهذه الأسباب.

قمنا بتعيين جميع التكوينات من خلال "config Yaml" لـ DM. ثم يقوم DM بإنشاء Configs ومتغيرات وقت التشغيل المناسبة ، ويقوم firebase deploy باسترداد وتعيين قيمهم في وقت النشر دون الحاجة إلى استخدام firebase config:set على الإطلاق. يتيح لنا هذا أيضًا إعداد موارد أخرى (مثل الحاويات والتحكم في الوصول إليها) وتعيين قيمها في RC دون الحاجة إلى توفيرها خارجيًا للقالب. بالإضافة إلى ذلك ، يتيح لنا ذلك استخدام أسماء المتغيرات وأسماء المتغيرات camelCase .

المرة الوحيدة التي نحدد فيها قيمة خارجيًا هي عندما نحتاج إلى تمرير مفتاح حساب خدمة (مشفر) من خلال تهيئة وقت التشغيل ، لأن DM لا يمكنه تشفير القيم بشكل آمن. لكننا ما زلنا نستخدم gcloud beta runtime-config configs variables set لذلك (بعد نشر DM وقبل firebase deploy ) وليس firebase config:set ، لأن السابق يقبل stdout من KMS.

أردت فقط أن أضيف - من خلال قراءة هذا يبدو أن بعض الناس فاتتهم نقطة حاسمة تؤدي إلى بعض الارتباك. سيكون من المفيد حقًا إذا تم توضيح ذلك في الوثائق أيضًا.

بشكل أساسي ، يستمر functions.config() بين _deployments_ ، ولكن يمكن أيضًا تعيينه بشكل منفصل بين مشاريع Firebase المختلفة!

هذا يعني أنه بالنسبة لبيئات التطوير والتشغيل المرحلي والإنتاج ، يجب عليك إعداد العديد من مشاريع Firebase المتطابقة (بدلاً من استخدام استضافة مواقع متعددة ، أو النشر في مشروع SAME ... 👎) والتي يحتفظ كل منها باستمرار بمتغيرات البيئة المختلفة .

بمجرد تعيين الأسماء المستعارة (أو التبديل بين المشاريع ذات firebase use ) ، يمكنك نشر نفس الريبو لمشاريع متعددة ومنفصلة في Firebase. هذه هي الطريقة التي تقوم بها بإعداد بيئة التطوير ، والتشغيل المرحلي ، والإنتاج - كمشاريع منفصلة لقاعدة Firebase.

بعد ذلك ، يمكنك تعيين تكوينات بيئة منفصلة لكل منها ، مثل هذا:
firebase -P dev config:set - اضبط المتغيرات لبيئة التطوير لديك
firebase -P prod config:set - اضبط المتغيرات لبيئة الإنتاج الخاصة بك ...

بعد ذلك ، يمكنك نشر نفس الريبو مرتين ، مثل:
firebase deploy -P dev
firebase deploy -P prod
وسينشر كلاهما ، في مشروع Firebase الخاص بهما ، وسيحتويان على تكوين بيئة منفصل خاص بهما سيستمر في الفترات الفاصلة بين عمليات النشر.

نعم ، هكذا نفعل ذلك أيضًا. مشاريع منفصلة لـ dev / test / prod.

مجرد مشاركة حل Vanilla JS الخاص بي والذي يعمل بخصوص النظام الأساسي الذي تقوم بتطويره على (Windows ، MacOS ، Linux):

استخدام مشاريع منفصلة لـ dev / test / prod.

/.firebaserc

{
  "projects": {
    "dev": "my-project-name-dev",
    "test": "my-project-name-test",
    "prod": "my-project-name-prod"
  }
}

ملفات التكوين

ملفات- JSON في المجلد /functions/config :

/functions/config/config.dev.json 
/functions/config/config.test.json 
/functions/config/config.prod.json 
/functions/config/config.SAMPLE.json <-- only file tracked in git

Example content:
{
    "google": {
        "key": "my-api-key",
        "storage_bucket": "firebase-storage-bucket"
    },
    "another_vendor": {
        "my_prop": "my value"
    },
    ...
}

/functions/set-config.js

const fs = require('fs');
const env = process.argv[2];

const configPath = `./config/config.${env}.json`;

if (!(configPath && fs.existsSync(configPath))) {
    return;
}

const collectConfigLines = (o, propPath, configLines) => {
    propPath = propPath || '';
    configLines = configLines || [];
    for (const key of Object.keys(o)) {
        const newPropPath = propPath + key;
        if (typeof o[key] === 'object') {
            collectConfigLines(o[key], newPropPath + '.', configLines);
        } else if (o[key] != null && o[key] !== '') {
            configLines.push(`${newPropPath}=${JSON.stringify(o[key])}`);
        }
    }
}

const config = require(configPath);
const configLines = [];
collectConfigLines(config, '', configLines);

const cp = require('child_process');
cp.execSync(`firebase -P ${env} functions:config:set ${configLines.join(' ')}`);

/functions/package.json

...
"scripts": {
    "config:set:dev": "node set-config dev",
    "config:set:test": "node set-config test",
    "config:set:prod": "node set-config prod",
    ...
},
...

إذا كان أي شخص لا يزال يبحث ، فهناك الطريقة المستخدمة في هذه المقالة المتوسطة https://medium.com/indielayer/deploying-environment-variables-with-firebase-cloud-functions-680779413484. أنقذ حياتي.

ما أفتقده شخصيًا هو القدرة على تعيين متغير التكوين دون إجراء نشر. لدينا خط أنابيب CICD يقوم بالنشر في بيئاتنا المختلفة ولا نريد أن يقوم المطور ببناء الكود محليًا ونشره ، لا سيما في الإنتاج. هكذا تنكسر الأشياء.

أيضًا إذا أردنا تغيير متغير موجود لاحقًا ، مع تطوير بعض الميزات ، يمكنك الآن التحقق من آخر علامة تم إصدارها ، وإنشاءها ، ونشرها ، وإعادتها إلى فرع الميزة الخاص بك ، والمتابعة. هذا حقا يجعل هذا غير قابل للاستخدام.

في الأساس ، نريد تكوينًا عن بُعد لوظائف السحابة

bezysoftware أعتقد أنك بحاجة إلى استخدام متغيرات البيئة (بدلاً من تكوين البيئة) ، يمكنك تخطي طبقة Firebase والقيام بذلك على منصة google cloud ، وتحقق من ذلك https://cloud.google.com/functions/docs/env- فار

شكرا لك على مشاركتك! تضمين التغريدة
كنت أرغب في الاستيراد من ملف ، لذلك استخدمت أمرًا مثل هذا.

firebase functions:config:set service_account="$(cat service-account.json)"

لقد قمت باستيراد ملف json لحساب الخدمة إلى Firebase Cloud Functions ، لأنني أردت استخدام واجهة برمجة تطبيقات إدارة المستخدم الخاصة بـ Firebase Admin SDK.

لم تنجح

@ Md-Abdul-Halim-Rafi

وظائف firebase

عملت من أجلي ، يمكنني رؤية var config بـ firebase functions:config:get .
لم ينجح في المرة الأولى لأنني لم أكن في مجلد المشروع ولم أحدد مشروع firebase الذي تريد تعيين متغير التكوين عليه ، لتحديد مشروع firebase باستخدام firebase use --add ، سيطالبك CLI بـ قائمة المشاريع على وحدة تحكم Firebase (بافتراض أنك قمت بتسجيل الدخول إلى CLI باستخدام firebase login )

تضمين التغريدة

وظائف firebase

يبدو أن هذا لن يعمل أثناء استخدام أي أنواع قيم أخرى في ملف json الخاص بك باستثناء السلاسل (على سبيل المثال ، منطقي أو رقم):

{
   "test": {
        "hmm": true
    }
}

فشل مع:

Error: HTTP Error: 400, Invalid value at 'variable.text' (TYPE_STRING), true

يبدو لي أنه من المعقول أن أكون قادرًا على القيام بما يلي:

firebase functions:config:get > config.json

وبعد ذلك:

firebase functions:config:set < config.json

من المنطقي أن يكون هذان الأمران متكاملين.

يسمح لي وجود التكوين في ملف بالتحكم في الإصدار ومعرفة كيف تغير بمرور الوقت.

من المؤسف أن الطريقة الوحيدة لتحقيق ذلك الآن (باستخدام env=$(cat config.json) ) تؤدي أيضًا إلى كسر قدرتي على أن تكون config.json هي القيم الفعلية لأنني لا أستطيع تغليفها بـ { env: ... } .

ملاحظة لنفسي: هذا هو المكان الذي أحتاج فيه لبدء طلب سحب الميزة: https://github.com/firebase/firebase-tools/blob/b17611a4ff0d36e157ed06a24f6c81d4e146d9e2/src/functionsConfig.js#L142

مجرد مشاركة حل Vanilla JS الخاص بي والذي يعمل بخصوص النظام الأساسي الذي تقوم بتطويره على (Windows ، MacOS ، Linux):

استخدام مشاريع منفصلة لـ dev / test / prod.

/.firebaserc

{
  "projects": {
    "dev": "my-project-name-dev",
    "test": "my-project-name-test",
    "prod": "my-project-name-prod"
  }
}

ملفات التكوين

ملفات- JSON في المجلد /functions/config :

/functions/config/config.dev.json 
/functions/config/config.test.json 
/functions/config/config.prod.json 
/functions/config/config.SAMPLE.json <-- only file tracked in git

Example content:
{
    "google": {
        "key": "my-api-key",
        "storage_bucket": "firebase-storage-bucket"
    },
    "another_vendor": {
        "my_prop": "my value"
    },
    ...
}

/functions/set-config.js

const fs = require('fs');
const env = process.argv[2];

const configPath = `./config/config.${env}.json`;

if (!(configPath && fs.existsSync(configPath))) {
    return;
}

const collectConfigLines = (o, propPath, configLines) => {
    propPath = propPath || '';
    configLines = configLines || [];
    for (const key of Object.keys(o)) {
        const newPropPath = propPath + key;
        if (typeof o[key] === 'object') {
            collectConfigLines(o[key], newPropPath + '.', configLines);
        } else if (o[key] != null && o[key] !== '') {
            configLines.push(`${newPropPath}=${JSON.stringify(o[key])}`);
        }
    }
}

const config = require(configPath);
const configLines = [];
collectConfigLines(config, '', configLines);

const cp = require('child_process');
cp.execSync(`firebase -P ${env} functions:config:set ${configLines.join(' ')}`);

/functions/package.json

...
"scripts": {
    "config:set:dev": "node set-config dev",
    "config:set:test": "node set-config test",
    "config:set:prod": "node set-config prod",
    ...
},
...

مجرد مشاركة حل Vanilla JS الخاص بي والذي يعمل بخصوص النظام الأساسي الذي تقوم بتطويره على (Windows ، MacOS ، Linux):

استخدام مشاريع منفصلة لـ dev / test / prod.

/.firebaserc

{
  "projects": {
    "dev": "my-project-name-dev",
    "test": "my-project-name-test",
    "prod": "my-project-name-prod"
  }
}

ملفات التكوين

ملفات JSON في المجلد /functions/config :

/functions/config/config.dev.json 
/functions/config/config.test.json 
/functions/config/config.prod.json 
/functions/config/config.SAMPLE.json <-- only file tracked in git

Example content:
{
    "google": {
        "key": "my-api-key",
        "storage_bucket": "firebase-storage-bucket"
    },
    "another_vendor": {
        "my_prop": "my value"
    },
    ...
}

/functions/set-config.js

const fs = require('fs');
const env = process.argv[2];

const configPath = `./config/config.${env}.json`;

if (!(configPath && fs.existsSync(configPath))) {
    return;
}

const collectConfigLines = (o, propPath, configLines) => {
    propPath = propPath || '';
    configLines = configLines || [];
    for (const key of Object.keys(o)) {
        const newPropPath = propPath + key;
        if (typeof o[key] === 'object') {
            collectConfigLines(o[key], newPropPath + '.', configLines);
        } else if (o[key] != null && o[key] !== '') {
            configLines.push(`${newPropPath}=${JSON.stringify(o[key])}`);
        }
    }
}

const config = require(configPath);
const configLines = [];
collectConfigLines(config, '', configLines);

const cp = require('child_process');
cp.execSync(`firebase -P ${env} functions:config:set ${configLines.join(' ')}`);

/functions/package.json

...
"scripts": {
    "config:set:dev": "node set-config dev",
    "config:set:test": "node set-config test",
    "config:set:prod": "node set-config prod",
    ...
},
...

معذرة ولكن متى تقوم بتشغيل البرنامج النصي " config: set : dev"؟ لم أفهم ... شكرا!