Firebase-tools: कार्यों के लिए JSON फ़ाइल स्वीकार करें:कॉन्फ़िगरेशन:सेट

मैं @jpreynat से सहमत डर रहे हैं जब हम अपने उत्पादन में तैनात करने से पहले एक config var सेट करना भूल जाते हैं। config.json के साथ हमारे कस्टम परिनियोजन स्क्रिप्ट में config:set को बांधना जोड़ा जाना एक अच्छी सुविधा होगी।
क्या अभी कोई वर्कअराउंड हैं, शायद कॉन्फिग में पाइपिंग?

ऐसा लगता है कि आप परियोजनाओं में कॉन्फ़िगरेशन को दोहराने की कोशिश कर रहे हैं। क्या firebase functions:config:clone आपके लिए काम करेगा?

कुछ संदर्भ देने के लिए, हम जानबूझकर फ़ाइल-आधारित कॉन्फ़िगरेशन से दूर हो गए हैं क्योंकि हमें लगता है कि यह खराब प्रथाओं को प्रोत्साहित करता है (अर्थात्, आपके कोड के साथ संग्रहीत रहस्यों से भरी फ़ाइल को रखना, संभावित रूप से आपके स्रोत भंडार में भी चेक किया गया)।

"आवश्यक" कॉन्फ़िगरेशन चर घोषित करने के लिए आप किसी तरह (यांत्रिकी टीबीडी) के बारे में क्या सोचेंगे - और यदि आपने वर्तमान प्रोजेक्ट में आवश्यक कॉन्फ़िगरेशन के बिना तैनात करने का प्रयास किया है तो कुछ भी बदलने से पहले यह त्रुटि हो जाएगी। क्या इससे आपकी मुख्य चिंताओं का समाधान हो जाएगा? यदि नहीं, तो फ़ाइल आपके लिए विशेष रूप से उपयोगी क्यों है?

@mbleeigh यही वही है जो मुझे नहीं पता था कि मैं चाहता था। अछा सुझाव!
संभवतः एक दिया गया/आपका मतलब 'मैकेनिक्स टीबीडी' से है, लेकिन: हमारे प्रोजेक्ट के भीतर किसी फ़ाइल में कुंजियों/कॉन्फ़िगरेशन संरचना को दूरस्थ रूप से परिभाषित करना, ताकि यह अन्य सभी चीज़ों की तरह git/PR समीक्षा प्रक्रिया से गुज़रे।
@jpreynat अपहरण की समस्या के लिए खेद है

@laurenzlong सलाह के लिए धन्यवाद, लेकिन हम एक विन्यास की नकल करने की कोशिश नहीं कर रहे हैं।
हमारी मुख्य चिंता हमारे परिनियोजन चरण के आधार पर विभिन्न परियोजनाओं के विन्यास को अद्यतन करना है।
तो मूल रूप से, हमारे पास प्रति पर्यावरण (देव, स्टेजिंग और प्रोड) एक कॉन्फ़िगरेशन फ़ाइल है, और क्रमशः फायरबेस कॉन्फ़िगरेशन सेट करें (पीआर के लिए, मास्टर और टैग पर पुश करें)।

@mbleeigh जानकारी के लिए धन्यवाद।
हालाँकि, हम निश्चित रूप से निश्चित नहीं हैं कि हम इन सभी envs को कॉन्फिग फाइलों का उपयोग करने के अलावा किसी अन्य तरीके से कैसे स्टोर कर सकते हैं।
वे वर्तमान में सरलता पढ़ने के लिए JSON के रूप में स्वरूपित हैं, लेकिन हम उन्हें सीधे functions:config:set कमांड में पास करने के लिए कुंजी/मूल्य जोड़े के रूप में स्वरूपित करने के बारे में सोच रहे हैं।
मैं आपसे सहमत हूँ कि यह JSON फ़ाइल पास करने से अधिक सुरक्षित नहीं है।
क्या आपके पास फाइलों का उपयोग करने के अलावा विभिन्न चरणों के लिए अपने पर्यावरण चर को कैसे संग्रहीत किया जा सकता है, इस पर कोई सिफारिश है?

@ahaverty कोई चिंता नहीं, मुझे खुशी है कि इस पर यहां बहस हो सकती है।

@jpreynat जब आप functions:config:set चलाते हैं तो इसे वर्तमान प्रोजेक्ट के साथ संग्रहीत किया जाता है। यदि आप प्रोजेक्ट के बीच स्विच करने के लिए firebase use का उपयोग कर रहे हैं, तो आपका कॉन्फिगरेशन स्थायी रहेगा। तो आप प्रति प्रोजेक्ट एक बार set चला सकते हैं और फिर यह हमेशा रहेगा। यह "विभिन्न वातावरणों के लिए अलग-अलग कॉन्फ़िगरेशन" समस्या को हल करना चाहिए, इसलिए शायद मैं वास्तविक समस्या को नहीं समझ रहा हूं?

@jpreynat मैं अभी के लिए इस मुद्दे को बंद करने जा रहा हूं, लेकिन अगर माइकल और मैंने आपके अनुरोध को गलत समझा है तो कृपया फिर से खोलें।

@laurenzlong @mbleigh क्षमा करें कि मैंने इस धागे पर जल्दी से उत्तर नहीं दिया।
हमें अभी के लिए इस समस्या का समाधान मिल गया है, लेकिन मेरे अनुरोध को स्पष्ट करने के लिए यहां कुछ संदर्भ दिए गए हैं:

हम ट्रैविस का उपयोग करके अपने ऐप को तैनात कर रहे हैं (ध्यान दें कि यह किसी भी सीआई या स्थानीय रूप से भी बहुत अच्छा होगा)। चूंकि हम शाखा और टैग के आधार पर अपने ऐप को विभिन्न चरणों में तैनात करते हैं, इसलिए पर्यावरण के आधार पर एक अलग JSON फ़ाइल का उपयोग करने में सक्षम होना बहुत अच्छा होगा।
उदाहरण के लिए, यह इस शर्त के आधार पर या तो firebase config:set -f staging.json या firebase config:set -f prod.json करने की अनुमति देगा।
हमारा समाधान नोड मॉड्यूल के रूप में firebase का उपयोग करना था, लेकिन हमें अभी भी अपने JSON कॉन्फ़िगरेशन को इनलाइन करना होगा, जो त्रुटियों से ग्रस्त है।

अरे @jpreynat मैं अभी भी आपके उत्तर से थोड़ा भ्रमित हूँ। एक बार जब आप कॉन्फ़िगरेशन को एक बार सेट करते हैं, तो यह हमेशा वहां रहता है, यहां तक ​​​​कि तैनाती के दौरान भी, जब तक कि आप फायरबेस फ़ंक्शन चलाकर कॉन्फ़िगरेशन मानों को अनसेट नहीं करते हैं

क्या कोई इसे फिर से खोल सकता है? %) @jpreynat @mbleeigh यह वास्तव में उन चीजों में से एक है जो गायब है। एटीएम मेरे पास लगभग 15 कॉन्फ़िगरेशन चर (और अधिक आने वाले) हैं और यह बहुत आसान होगा यदि functions:config:set किसी तरह से JSON स्वीकार कर सकता है।

"आवश्यक" कॉन्फ़िगरेशन चर घोषित करने पर @mbleeigh सुझाव के लिए हमसे बड़ा वोट - और यदि आपने वर्तमान प्रोजेक्ट में आवश्यक कॉन्फ़िगरेशन के बिना तैनात करने का प्रयास किया है तो कुछ भी बदलने से पहले यह त्रुटि हो जाएगी।
हमारे लिए भी एक दर्द बिंदु बनना, लेकिन यह हमारे सभी मुद्दों को हल करेगा और संस्करण नियंत्रण/समीक्षा प्रक्रिया में अच्छी तरह फिट होगा

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

अरे @yaronyosef आप सीधे : config : सेट कमांड, यह सिर्फ इतना है कि आपको इसे अपने प्लेटफॉर्म के लिए उपयुक्त तरीके से प्रारूपित करना होगा। लिनक्स के लिए, निम्नलिखित कार्य करना चाहिए:

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

साझा करने के लिए आपका धन्यवाद। @laurenzlong
मैं एक फाइल से आयात करना चाहता था, इसलिए मैंने इस तरह कमांड का इस्तेमाल किया।

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

मैंने फ़ायरबेस क्लाउड फ़ंक्शंस में एक सेवा खाता जेसन फ़ाइल आयात की, क्योंकि मैं फ़ायरबेस एडमिन एसडीके के उपयोगकर्ता प्रबंधन एपीआई का उपयोग करना चाहता था।

कूल उपयोग का मामला! साझा करने के लिए धन्यवाद!

हम गिट के माध्यम से गैर-गुप्त कॉन्फ़िगरेशन को ट्रैक करना भी पसंद करेंगे, जहां प्रतिबद्ध JSON रनटाइम कॉन्फ़िगरेशन फ़ाइलें (एकाधिक वातावरण के लिए) आधिकारिक होंगी और सीआई पर्यावरण तब किसी विशेष वातावरण से संबंधित फ़ाइल से functions:config:set लागू होगा (और प्रत्येक परिवेश एक अलग Firebase प्रोजेक्ट से मेल खाता है)।

यदि आप गिट में कॉन्फ़िगरेशन रखते हैं, तो उन्हें अपने फ़ंक्शन रनटाइम में पढ़ने के लिए छोटा है। बस उन्हें 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);
}

फायरबेस द्वारा उपयोग किए जाने वाले रनटाइम कॉन्फ़िगरेशन को विशेष रूप से गिट में कॉन्फ़िगरेशन चेक करने से बचने के लिए डिज़ाइन किया गया है, क्योंकि (विशेष रूप से रहस्यों के साथ) हमने इसे एक पैटर्न के रूप में पाया है जो हल होने की तुलना में अधिक समस्याओं का कारण बनता है।

यह सच है, हालांकि तब हम इस उद्देश्य के लिए कॉन्फिग एपीआई का बिल्कुल भी उपयोग नहीं करते हैं। संवेदनशील मानों को संग्रहीत करने के लिए अभी भी कॉन्फिग एपीआई के माध्यम से जाना फायदेमंद हो सकता है (जो कि फायरबेस डॉक्स के आधार पर एक उपयुक्त उपयोग का मामला लगता है) और स्रोत-नियंत्रित और ट्रैक न किए गए दोनों मानों को एक ही सटीक तरीके से लोड करें (यानी 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

आखिरकार, यह भी आवश्यक नहीं हो सकता है यदि कॉन्फिग एपीआई ने सभी परिवर्तनों के उपयोग में आसान ऑडिट ट्रेल्स को सक्षम किया है (कृपया मुझे सही करें यदि यह पहले से ही मामला है, तो मैं इसे एक्सप्लोर करना चाहता हूं)।

तो यह कैसे साथ आ रहा है? मैं

@mbleeigh सुझाव को अभी भी लागू होते देखना पसंद करेंगे! हमें अपने गैर-देव लक्ष्यों पर कॉन्फ़िगरेशन सेट करना भूलने में लगातार समस्याएं आ रही हैं

थ्रेड बंप के लिए धन्यवाद। रिपोर्ट करने के लिए अभी कुछ नहीं है, लेकिन मैं इसे अपनी योजना बैठकों में फिर से लाऊंगा ताकि यह देखा जा सके कि क्या हम इस पर कुछ प्रगति करना शुरू कर सकते हैं।

मैं यह सुनिश्चित करने के लिए JSON स्कीमा फ़ाइल के साथ अपनी कॉन्फ़िगरेशन को सत्यापित करता हूं कि इसमें मेरे द्वारा अपेक्षित सभी मान हैं। यह सत्यापन मेरी सीआई पाइपलाइन का हिस्सा है और अगर यह विफल रहता है तो तैनाती को रोकता है। यदि मेरी तरह आप अपने कार्यों को लिखने के लिए टाइपस्क्रिप्ट का उपयोग करते हैं, तो आप अपने प्रकार से JSON स्कीमा उत्पन्न कर सकते हैं।

यह बहुत अच्छा काम करता है, इस सीमा के साथ कि फ़ंक्शन कॉन्फ़िगरेशन केवल स्ट्रिंग्स को स्वीकार करता है, इसलिए स्कीमा यह सत्यापित नहीं कर सकता कि कॉन्फ़िगरेशन मान एक संख्या है। बूलियन के लिए यह ठीक है क्योंकि मैं केवल मान्य मानों के रूप में "true" और "false" साथ एक एनम का उपयोग कर सकता हूं।

संदर्भ के लिए मेरी सर्किलसीआई कॉन्फ़िगरेशन और यह ब्लॉग पोस्ट देखें।

@hgwood साझा करने के लिए धन्यवाद! हम निश्चित रूप से इसे अपने सीआई में भी शामिल करेंगे।

बस इस "समस्या" के लिए अपना समाधान छोड़ना चाहता था, और चर्चा पर मेरे विचार:

1. मैं समझता हूं कि गुप्त/संवेदनशील मूल्यों को रेपो में संग्रहित नहीं किया जाना चाहिए। मेरा समाधान केवल गैर-गुप्त मूल्यों के लिए है। गुप्त मान मैन्युअल रूप से सेट किए जाते हैं, लेकिन कॉन्फ़िगरेशन मानों को आवश्यकतानुसार चिह्नित करने का एक तरीका उन गुप्त मानों के लिए अद्भुत होगा।
2. मुझे लगता है कि कुछ लोगों के विचार से यह अधिक महत्वपूर्ण है। विभिन्न परिनियोजन पर्यावरण परियोजनाओं के लिए अलग-अलग कॉन्फ़िगरेशन मानों को मैन्युअल रूप से सेट करना एक PITA है, और एक साथ उन्हें आसानी से देखने/तुलना करने में सक्षम नहीं है। फ़ाइलों में कॉन्फ़िगरेशन को परिभाषित करने से प्रक्रिया बहुत कम परेशानी वाली हो जाती है।
3. मुझे लगता है कि वेब कंसोल में एक फ़ंक्शन कॉन्फ़िगरेशन संपादक जोड़ने से इसमें बहुत सुधार होगा, लेकिन यह वास्तव में अच्छा होगा यदि एक साथ कई परियोजनाओं के लिए कॉन्फ़िगरेशन देखने का कोई तरीका हो, ताकि आप आसानी से विभिन्न परिनियोजन वातावरण के लिए कॉन्फ़िगरेशन की तुलना कर सकें।
4. मैं हमेशा से कह रहा हूं कि फायरबेस को एक ही परियोजना के भीतर वातावरण को परिभाषित करने की अनुमति देने की आवश्यकता है, इसलिए आपको परिनियोजन वातावरण के रूप में उपयोग करने के लिए कई परियोजनाओं की आवश्यकता नहीं है। यदि यह अस्तित्व में है, तो एक ही प्रोजेक्ट के भीतर कई वातावरणों के लिए कॉन्फ़िगरेशन को एक साथ देखना बहुत आसान होगा।
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

फिर, मैंने एक छोटी नोड स्क्रिप्ट लिखी है जो हल किए गए कॉन्फ़िगरेशन को लोड करती है, और कुंजी = वैल जोड़े की एक स्पेस-सीमांकित सूची लौटाती है

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(' '))

सीआई परिनियोजन के दौरान, मैं कुंजी = वैल जोड़े प्राप्त करने के लिए इस बैश शैल स्क्रिप्ट का उपयोग करता हूं और उन्हें फ़ंक्शंस के साथ सेट करता हूं

# 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 त्रुटि का सामना नहीं करना पड़ा?

हमने इन कारणों से परिनियोजन प्रबंधक का उपयोग करना समाप्त कर दिया।

हम डीएम के लिए "कॉन्फ़िगर यमल" के माध्यम से सभी कॉन्फ़िगरेशन सेट करते हैं। फिर डीएम उपयुक्त रनटाइम कॉन्फिग और वेरिएबल्स बनाता है, और firebase deploy पुनर्प्राप्त करता है और firebase config:set का उपयोग किए बिना तैनाती समय पर उनके मान सेट करता है। यह हमें अन्य संसाधनों (जैसे बाल्टी और उनके अभिगम नियंत्रण) को स्थापित करने और टेम्पलेट को बाहरी रूप से आपूर्ति किए बिना आरसी में उनके मूल्यों को सेट करने की अनुमति देता है। इसके अतिरिक्त, यह हमें camelCase कॉन्फ़िगरेशन और चर नामों का उपयोग करने की अनुमति देता है।

जब हम बाहरी रूप से एक मान सेट करते हैं, तब हमें रनटाइम कॉन्फ़िगरेशन के माध्यम से एक (एन्क्रिप्टेड) ​​​​सेवा खाता कुंजी पास करने की आवश्यकता होती है, क्योंकि डीएम सुरक्षित रूप से मूल्यों को एन्क्रिप्ट नहीं कर सकता है। लेकिन हम अभी भी उसके लिए gcloud beta runtime-config configs variables set का उपयोग करते हैं (DM परिनियोजन के बाद और firebase deploy ) और firebase config:set , क्योंकि पूर्व KMS से स्टडआउट स्वीकार करता है।

मैं बस जोड़ना चाहता था - इसके माध्यम से पढ़ने से ऐसा लगता है कि कुछ लोग एक महत्वपूर्ण बिंदु से चूक गए जिससे कुछ भ्रम पैदा हो गया। यह वास्तव में उपयोगी होगा यदि इसे दस्तावेज़ीकरण में भी साफ़ कर दिया गया हो।

मूल रूप से, functions.config() _deployments_ के बीच में बना रहता है, लेकिन अलग-अलग फायरबेस परियोजनाओं के बीच अलग से भी सेट किया जा सकता है!

इसका मतलब यह है कि देव, मंचन और उत्पादों के वातावरण के लिए, आपको कई समान फायरबेस प्रोजेक्ट स्थापित करने होंगे (बहु-साइट होस्टिंग का उपयोग करने के बजाय, या एक ही प्रोजेक्ट पर तैनात करने के लिए... ) जिनमें से प्रत्येक लगातार अपने स्वयं के अलग-अलग पर्यावरण चर रखता है। .

एक बार जब आप उपनाम सेट कर लेते हैं (या केवल firebase use परियोजनाओं के बीच स्विच कर लेते हैं) तो आप एक ही रेपो को एकाधिक, अलग फायरबेस परियोजनाओं में तैनात कर सकते हैं। अलग-अलग फायरबेस परियोजनाओं के रूप में - इस तरह आप एक देव वातावरण, मंचन और उत्पादन स्थापित करते हैं।

फिर, आप प्रत्येक के लिए अलग परिवेश कॉन्फ़िगरेशन सेट कर सकते हैं, जैसे:
firebase -P dev config:set - अपने विकास के लिए चर सेट करें env
firebase -P prod config:set - अपने उत्पादन परिवेश के लिए चर सेट करें...

फिर, आप एक ही रेपो को दो बार तैनात कर सकते हैं, जैसे:
firebase deploy -P dev
firebase deploy -P prod
और वे दोनों अपने-अपने फायरबेस प्रोजेक्ट में परिनियोजित करेंगे, और उनका अपना, अलग पर्यावरण विन्यास होगा जो तैनाती के बीच में बना रहेगा।

हां, हम भी ऐसा ही करते हैं। देव/परीक्षण/उत्पाद के लिए अलग परियोजनाएं।

बस मेरे वेनिला जेएस समाधान को साझा करना जो आपके द्वारा विकसित किए गए प्लेटफॉर्म (विंडोज, मैकओएस, लिनक्स) के संबंध में काम करता है:

देव/परीक्षण/उत्पाद के लिए अलग-अलग परियोजनाओं का उपयोग करना।

/.फायरबेसर

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

कॉन्फ़िग फ़ाइलें

/functions/config फ़ोल्डर में JSON-फ़ाइलें:

/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 मुझे लगता है कि आपको पर्यावरण चर (पर्यावरण विन्यास के बजाय) का उपयोग करने की आवश्यकता है, आप फायरबेस परत को छोड़ सकते हैं और इसे Google क्लाउड प्लेटफॉर्म पर कर सकते हैं, इसे देखें https://cloud.google.com/functions/docs/env- वर

साझा करने के लिए आपका धन्यवाद। @laurenzlong
मैं एक फाइल से आयात करना चाहता था, इसलिए मैंने इस तरह कमांड का इस्तेमाल किया।

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

मैंने फ़ायरबेस क्लाउड फ़ंक्शंस में एक सेवा खाता जेसन फ़ाइल आयात की, क्योंकि मैं फ़ायरबेस एडमिन एसडीके के उपयोगकर्ता प्रबंधन एपीआई का उपयोग करना चाहता था।

यह काम नहीं किया

@मद-अब्दुल-हलीम-रफी

फायरबेस फ़ंक्शन: कॉन्फिग : सेट service_account = "$ (बिल्ली सेवा-खाता.जेसन)"

मेरे लिए काम किया, मैं config var को firebase functions:config:get साथ देख सकता हूं।
यह पहली बार काम नहीं किया क्योंकि मैं प्रोजेक्ट फ़ोल्डर में नहीं था और फायरबेस प्रोजेक्ट का चयन नहीं किया था, जिस पर कॉन्फिग वेरिएबल सेट करना है, फायरबेस प्रोजेक्ट का चयन करने के लिए firebase use --add , सीएलआई आपको संकेत देगा आपके फायरबेस कंसोल पर परियोजनाओं की सूची (यह मानते हुए कि आप CLI में firebase login साथ लॉग इन हैं)

@dnhyde

फायरबेस फ़ंक्शन: कॉन्फिग : सेट service_account = "$ (बिल्ली सेवा-खाता.जेसन)"

ऐसा लगता है कि यह आपकी 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

बस मेरे वेनिला जेएस समाधान को साझा करना जो आपके द्वारा विकसित किए गए प्लेटफॉर्म (विंडोज, मैकओएस, लिनक्स) के संबंध में काम करता है:

देव/परीक्षण/उत्पाद के लिए अलग-अलग परियोजनाओं का उपयोग करना।

/.फायरबेसर

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

कॉन्फ़िग फ़ाइलें

/functions/config फ़ोल्डर में JSON-फ़ाइलें:

/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",
    ...
},
...

बस मेरे वेनिला जेएस समाधान को साझा करना जो आपके द्वारा विकसित किए गए प्लेटफॉर्म (विंडोज, मैकओएस, लिनक्स) के संबंध में काम करता है:

देव/परीक्षण/उत्पाद के लिए अलग-अलग परियोजनाओं का उपयोग करना।

/.फायरबेसर

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

कॉन्फ़िग फ़ाइलें

/functions/config फ़ोल्डर में JSON-फ़ाइलें:

/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" स्क्रिप्ट कब चलाते हैं? मुझे समझ नहीं आया... धन्यवाद!