Generate CloudEvents in the PubSub Emulator #3767

taeold · 2021-09-21T02:47:52Z

Update PubSub Emulator to emit events in CloudEvent format given a trigger whose function signature is cloudevent.

Previously, the Functions Emulator considered 2 types of functions - https and background. With the introduction of CloudEvents in Google Cloud Functions, we now have 2 types of background functions - legacy vs cloudevent. For example:

/* Legacy Events */
exports.helloPubSub = functions.pubsub.topic('topic-name').onPublish((message) => {
  // ...
});

/* CloudEvents */
exports.helloPubSub = functions.v2.pubsub.topic('topic-name').onPublish((cloudevent) => {
  const message = cloudevent.data.message;
});

To accommodate, we adopt concept of "function signature" introduced in Google Cloud Function's Functions Framework to categorize each function trigger as one of http, event, orcloudevent.

When registering a function trigger with the Pubsub emulator, the functions's signature type will be included in the registration request, and the Pubsub emulator will use the info to emit an event in the format expected by the underlying function trigger. We also make minor changes to the Functions Emulator to selectively massage the incoming events in-route to the function trigger.

As an added bonus, we are now able to remove triggerType field in the FunctionsRuntimeArg as that info is now outdated and not needed when invoking an emulated function.

triggerType is no longer needed in FunctionsRuntimeBundle due to environment variables refactor. In preparation for CloudEvent integration, we rename signatureType to more apporpriate signatureType which can be one of 'http' or 'event'. This follows the same convention used by the GCF functions framework and prepares us to provide supporrt for 'cloudevent' function signature.

scripts/integration-helpers/framework.ts

src/emulator/functionsEmulator.ts

src/emulator/functionsEmulatorRuntime.ts

src/emulator/functionsEmulatorShared.ts

src/emulator/pubsubEmulator.ts

inlined

Great work. Between it being late and my lack of familiarity I shouldn't be the final approver, but LGTM.

scripts/triggers-end-to-end-tests/functions/index.js

src/emulator/functionsEmulator.ts

src/emulator/functionsEmulatorRuntime.ts

inlined · 2021-09-22T04:50:16Z

src/emulator/functionsEmulatorShared.ts

+  if (def.httpsTrigger) {
+    return "http";
+  }
+  return def.platform === "gcfv2" ? "cloudevent" : "event";


Is this our product decision? That "compat mode" where firebase-functions/v1 is used for GCFv2 or firebase-functions/v2 is used for GCFv1 isn't supported in the emulator?

We need to think deeply about how that scenario should work, but it's too late for me to think deeply tonight.

This is a practical decision - AFAIK there aren't any info I can use in the trigger definition to distinguish functions expecting events in legacy or cloudevent format. I'll add a todo for us to update this logic once we have a path forward on how declarative function signature will work w/ the Firebase Functions SDK.

WDYT about the idea that we'll use the FUNCTION_SIGNATURE_TYPE env variable in the SDK if the event type doesn't match the default for the platform? So if someone does functions.runWith({platform: "gcfv2"}).pubsub.topic('foo').onPublish(handler) we'll add FUNCTION_SIGNATURE_TYPE=event in the env annotation.

So that just means that we need to check the env variable here before we check platform.

inlined · 2021-09-22T04:52:15Z

src/emulator/pubsubEmulator.ts

+    if (
+      triggers.some((t) => t.triggerKey === triggerKey) &&
+      this.subscriptionForTopic.has(topicName)
+    ) {
      this.logger.logLabeled("DEBUG", "pubsub", "Trigger already exists");


Couldn't two functions listen to the same topic?

Yes that should work?

inlined · 2021-09-22T04:54:03Z

src/emulator/pubsubEmulator.ts

+      const ce = HTTP.structured(
+        new CloudEvent({
+          type: "google.cloud.pubsub.topic.v1.messagePublished",
+          source: `//pubsub.googleapis.com/projects/${this.args.projectId}/topics/${topic}`,


Really? It's all source and none of it is subject?

🤷 That's what I saw:

src/emulator/pubsubEmulator.ts

…se/firebase-tools into dl-cf3-cloudevents-pubsub

Update PubSub Emulator to emit events in CloudEvent format given a trigger whose function signature is `cloudevent`. Previously, the Functions Emulator considered 2 types of functions - `https` and `background`. With the introduction of [CloudEvents](https://cloud.google.com/functions/docs/writing/cloudevents) in Google Cloud Functions, we now have 2 types of `background` functions - `legacy` vs `cloudevent`. For example: ```js /* Legacy Events */ exports.helloPubSub = functions.pubsub.topic('topic-name').onPublish((message) => { // ... }); /* CloudEvents */ exports.helloPubSub = functions.v2.pubsub.topic('topic-name').onPublish((cloudevent) => { const message = cloudevent.data.message; }); ``` To accommodate, we adopt concept of "function signature" introduced in Google Cloud Function's [Functions Framework](https://github.com/GoogleCloudPlatform/functions-framework-nodejs) to categorize each function trigger as one of `http`, `event`, or`cloudevent`. When registering a function trigger with the Pubsub emulator, the functions's signature type will be included in the registration request, and the Pubsub emulator will use the info to emit an event in the format expected by the underlying function trigger. We also make minor changes to the Functions Emulator to selectively massage the incoming events in-route to the function trigger. As an added bonus, we are now able to remove `triggerType` field in the `FunctionsRuntimeArg` as that info is now outdated and not needed when invoking an emulated function.

inlined · 2021-09-27T18:34:32Z

src/emulator/events/types.ts

+   * part of the CloudEvents spec nor the payload that a Cloud Function
+   * actually receives.
+   */
+  params?: Record<string, string>;


Params isn't part of the wire protocol, so we should be able to keep it out of the CLI.

inlined · 2021-09-27T18:37:02Z

src/emulator/functionsEmulatorShared.ts

+  if (def.httpsTrigger) {
+    return "http";
+  }
+  return def.platform === "gcfv2" ? "cloudevent" : "event";


WDYT about the idea that we'll use the FUNCTION_SIGNATURE_TYPE env variable in the SDK if the event type doesn't match the default for the platform? So if someone does functions.runWith({platform: "gcfv2"}).pubsub.topic('foo').onPublish(handler) we'll add FUNCTION_SIGNATURE_TYPE=event in the env annotation.

So that just means that we need to check the env variable here before we check platform.

@colerogers

* Trigger discovery now includes Endpoints (#3752) * Fork translator implementations * TriggerDiscovery now records Endpoints as well as Specs * Remove debug print * Start moving over cases of existingBackend (#3753) * Fork translator implementations * TriggerDiscovery now records Endpoints as well as Specs * Remove debug print * Start moving over existing use cases * Migrate the deploy codebase aside from release code (#3754) * Fork translator implementations * TriggerDiscovery now records Endpoints as well as Specs * Remove debug print * Start moving over existing use cases * Migrate the deploy codebase aside from release code * PR feedback * Use eventType to infer service from function trigger definition in the Emulator. (#3712) * Refactor in preparation for adding multitenancy support (#3746) This change introduces the refactor discussed in go/emulator-multi-tenancy. Main changes include: * Updating how `ProjectState` is indexed in `getProjectStateById()` * Extending `ProjectState` with `AgentProjectState` and `TenantProjectState` Corresponding internal bug: b/192387245 * Add MFA support for Auth Emulator (#3732) * Update API schema from discovery. * WIP: Add MFA support. * Implement withdraw and token fields. * Add error handling for most cases. * Clean up some comments. * Support MFA in batchCreate. * Properly support MFA for emailLink and IDP. * Address review feedback. * Clean up more TODOs. * Update gen-auth-api-spec.ts to use flatPath instead of path (#3761) Add preprocessing logic to use flatPaths instead of paths in discovery object. Some endpoints/methods have the same path, which led to endpoints being overwritten and not appearing in apiSpec.js (e.g. see identitytoolkit.projects.inboundSamlConfigs.delete and identitytoolkit.projects.defaultSupportedIdpConfigs.delete in v2 discovery docs). To work around this, use the flatPath which are distinct between overloaded paths. This change largely impacts paths that have params with slashes in them, which is currently not supported by OpenAPI. Corresponding internal bug: b/199768026 * Adding noninteractive support to ext:dev:publish (#3745) * Adding noninteractive support to ext:dev:publish * Add --non-interactive and --force support to ext:update (#3749) * ext:update now supports --non-interactive and --force * fixed test * add changelog * formats * Extract environment variables initialization out of Functions Emulator Runtime. (#3707) As a step towards standardizing Functions Runtime environment, we extract all logic for initializing environment variables for a n emulated function out of the `FunctionsEmulatorRuntime` and place them in the caller (`FunctionsEmulator`). All behaviors should remain the same minus the following details: 1. Environment variable values will not change once the runtime has started. Env vars like `FUNCTIONS_TARGET` might look like it should change per function invocation, but since each worker is associated with a trigger,`FUNCTION_TARGET` won't actually ever change. This may be a problem though if other emulators (e.g. storage emulator) is started _after_ the functions emulator is started and a function is invoked. (I don't think this is a common use case?). 2. We no longer check user's Functions SDK version to optionally override realtime emulator path. I think it's actually better to fail the emulator IF user has configured realtime database emulator and using an unsupported version of the functions SDK rather than silently talking to the prod database. I can be convinced otherwise though. * security(deps): proxy-agent@5.0.0 (CVE-2021-23406) (#3757) https://snyk.io/vuln/SNYK-JS-PACRESOLVER-1564857 firebase-tools@9.17.0 requires pac-resolver@^4.1.0 via a transitive dependency on pac-proxy-agent@4.1.0. upgrading to proxy-agent@5.0.0 causes pac-resolver to get upgraded to 5.0.0, resolving the issue. Co-authored-by: Bryan Kendall <bkend@google.com> * adding externalServices to extensions types (#3766) * fix login:use and account resolution issue (#3773) * Minor fixes for Auth Emulator IDP widget. (#3774) * Minor fixes for Auth Emulator IDP widget. * Changelog. * Move ref parsing code to a separate file. (#3779) * migrating parseRef to ref * moving ref parsing into its own file * add jsdocs * renaming to refs * forgot to save * Generate CloudEvents in the PubSub Emulator (#3767) Update PubSub Emulator to emit events in CloudEvent format given a trigger whose function signature is `cloudevent`. Previously, the Functions Emulator considered 2 types of functions - `https` and `background`. With the introduction of [CloudEvents](https://cloud.google.com/functions/docs/writing/cloudevents) in Google Cloud Functions, we now have 2 types of `background` functions - `legacy` vs `cloudevent`. For example: ```js /* Legacy Events */ exports.helloPubSub = functions.pubsub.topic('topic-name').onPublish((message) => { // ... }); /* CloudEvents */ exports.helloPubSub = functions.v2.pubsub.topic('topic-name').onPublish((cloudevent) => { const message = cloudevent.data.message; }); ``` To accommodate, we adopt concept of "function signature" introduced in Google Cloud Function's [Functions Framework](https://github.com/GoogleCloudPlatform/functions-framework-nodejs) to categorize each function trigger as one of `http`, `event`, or`cloudevent`. When registering a function trigger with the Pubsub emulator, the functions's signature type will be included in the registration request, and the Pubsub emulator will use the info to emit an event in the format expected by the underlying function trigger. We also make minor changes to the Functions Emulator to selectively massage the incoming events in-route to the function trigger. As an added bonus, we are now able to remove `triggerType` field in the `FunctionsRuntimeArg` as that info is now outdated and not needed when invoking an emulated function. * Add Endpoints version of DeploymentPlanner (#3756) * Fork translator implementations * TriggerDiscovery now records Endpoints as well as Specs * Remove debug print * Start moving over existing use cases * Migrate the deploy codebase aside from release code * Migrate deploymentPlanner * Make code easier to review * PR feedback * Start inferring wantBackend details from existingBackend (#3790) * Start inferring wantBackend details from existingBackend * Update src/test/deploy/functions/prepare.spec.ts Co-authored-by: Daniel Lee <danielylee@google.com> Co-authored-by: Daniel Lee <danielylee@google.com> * Adds Fabricator to release code (#3807) * Adds Fabricator to release code Fabricator is the repalcement for the old Tasks codebase, though it will not handle the portion of tracking or error reporting internally (those will be future utilities for better testing). Some differences between tasks.ts and fabricator.ts: * Queues are used for narrow transactions, which means we don't accidentally have an error bubble up and cause a retry on a bulk operation. There's a design pattern of executor.run.catch(rethrowAs) * Function triggers (not EventArc triggers, which are deployed as part of the function, but external triggers like topics, and in the future intents or task queues) are only created after a successful function creation and functions are only deleted after a successful trigger deletion * We do not delete functions if an upsert failed (this helps catch cases where a user renamed a function) * This code is actually unit tested (hooray!) * Delete scratch space code * PR feedback + tests & fixes for SourceTokenScraper * Merge master; backport recent changes (#3816) Merge master; backport @colerogers' changes to Endpoint code. * Add metrics and error reporting to release code (#3815) Adds Fabricator to release code Fabricator is the repalcement for the old Tasks codebase, though it will not handle the portion of tracking or error reporting internally (those will be future utilities for better testing). Some differences between tasks.ts and fabricator.ts: * Queues are used for narrow transactions, which means we don't accidentally have an error bubble up and cause a retry on a bulk operation. There's a design pattern of executor.run.catch(rethrowAs) * Function triggers (not EventArc triggers, which are deployed as part of the function, but external triggers like topics, and in the future intents or task queues) are only created after a successful function creation and functions are only deleted after a successful trigger deletion * We do not delete functions if an upsert failed (this helps catch cases where a user renamed a function) * This code is actually unit tested (hooray!) * Move firebase functions:delete to use Endpoints code (#3821) * Move functions:delete to endpoints code * Remove old functions delete code * Make container contract parsing use Endpoints (#3826) * Inlined.endpoints 9.6.discovery (#3830) * Make container contract parsing use Endpoints * Finish the endpoints refactor! (#3827) * Delete dead code; make a few fixes as I discover them * Free up 12LOC to meet budget * Fixes from bugbashing (#3832) * Don't obscure helpful error messages * Functions should have deployment-tool label and functions:delete shouldn't need it * Lost commit? Record URI after deploys for future printing * Lint fixes * Alternative deploymentTool fix * get rid of extra space in logOpStart * Don't cache trigger regions if the trigger changed * functions list should list ID not entrypoint * Fix compiler erro * Rewrite trigger region copy code * Enablement of APIs should have 'functions' prefix * Remember old trigger region. Recreate Fn when it changes * Run formatter Co-authored-by: Daniel Lee <danielylee@google.com> Co-authored-by: Lisa Jian <lisajian@google.com> Co-authored-by: Yuchen Shi <yuchenshi@google.com> Co-authored-by: joehan <joehanley@google.com> Co-authored-by: Avi Vahl <avi.vahl@wix.com> Co-authored-by: Bryan Kendall <bkend@google.com>

Update PubSub Emulator to emit events in CloudEvent format given a trigger whose function signature is `cloudevent`. Previously, the Functions Emulator considered 2 types of functions - `https` and `background`. With the introduction of [CloudEvents](https://cloud.google.com/functions/docs/writing/cloudevents) in Google Cloud Functions, we now have 2 types of `background` functions - `legacy` vs `cloudevent`. For example: ```js /* Legacy Events */ exports.helloPubSub = functions.pubsub.topic('topic-name').onPublish((message) => { // ... }); /* CloudEvents */ exports.helloPubSub = functions.v2.pubsub.topic('topic-name').onPublish((cloudevent) => { const message = cloudevent.data.message; }); ``` To accommodate, we adopt concept of "function signature" introduced in Google Cloud Function's [Functions Framework](https://github.com/GoogleCloudPlatform/functions-framework-nodejs) to categorize each function trigger as one of `http`, `event`, or`cloudevent`. When registering a function trigger with the Pubsub emulator, the functions's signature type will be included in the registration request, and the Pubsub emulator will use the info to emit an event in the format expected by the underlying function trigger. We also make minor changes to the Functions Emulator to selectively massage the incoming events in-route to the function trigger. As an added bonus, we are now able to remove `triggerType` field in the `FunctionsRuntimeArg` as that info is now outdated and not needed when invoking an emulated function.

@colerogers

* Trigger discovery now includes Endpoints (firebase#3752) * Fork translator implementations * TriggerDiscovery now records Endpoints as well as Specs * Remove debug print * Start moving over cases of existingBackend (firebase#3753) * Fork translator implementations * TriggerDiscovery now records Endpoints as well as Specs * Remove debug print * Start moving over existing use cases * Migrate the deploy codebase aside from release code (firebase#3754) * Fork translator implementations * TriggerDiscovery now records Endpoints as well as Specs * Remove debug print * Start moving over existing use cases * Migrate the deploy codebase aside from release code * PR feedback * Use eventType to infer service from function trigger definition in the Emulator. (firebase#3712) * Refactor in preparation for adding multitenancy support (firebase#3746) This change introduces the refactor discussed in go/emulator-multi-tenancy. Main changes include: * Updating how `ProjectState` is indexed in `getProjectStateById()` * Extending `ProjectState` with `AgentProjectState` and `TenantProjectState` Corresponding internal bug: b/192387245 * Add MFA support for Auth Emulator (firebase#3732) * Update API schema from discovery. * WIP: Add MFA support. * Implement withdraw and token fields. * Add error handling for most cases. * Clean up some comments. * Support MFA in batchCreate. * Properly support MFA for emailLink and IDP. * Address review feedback. * Clean up more TODOs. * Update gen-auth-api-spec.ts to use flatPath instead of path (firebase#3761) Add preprocessing logic to use flatPaths instead of paths in discovery object. Some endpoints/methods have the same path, which led to endpoints being overwritten and not appearing in apiSpec.js (e.g. see identitytoolkit.projects.inboundSamlConfigs.delete and identitytoolkit.projects.defaultSupportedIdpConfigs.delete in v2 discovery docs). To work around this, use the flatPath which are distinct between overloaded paths. This change largely impacts paths that have params with slashes in them, which is currently not supported by OpenAPI. Corresponding internal bug: b/199768026 * Adding noninteractive support to ext:dev:publish (firebase#3745) * Adding noninteractive support to ext:dev:publish * Add --non-interactive and --force support to ext:update (firebase#3749) * ext:update now supports --non-interactive and --force * fixed test * add changelog * formats * Extract environment variables initialization out of Functions Emulator Runtime. (firebase#3707) As a step towards standardizing Functions Runtime environment, we extract all logic for initializing environment variables for a n emulated function out of the `FunctionsEmulatorRuntime` and place them in the caller (`FunctionsEmulator`). All behaviors should remain the same minus the following details: 1. Environment variable values will not change once the runtime has started. Env vars like `FUNCTIONS_TARGET` might look like it should change per function invocation, but since each worker is associated with a trigger,`FUNCTION_TARGET` won't actually ever change. This may be a problem though if other emulators (e.g. storage emulator) is started _after_ the functions emulator is started and a function is invoked. (I don't think this is a common use case?). 2. We no longer check user's Functions SDK version to optionally override realtime emulator path. I think it's actually better to fail the emulator IF user has configured realtime database emulator and using an unsupported version of the functions SDK rather than silently talking to the prod database. I can be convinced otherwise though. * security(deps): proxy-agent@5.0.0 (CVE-2021-23406) (firebase#3757) https://snyk.io/vuln/SNYK-JS-PACRESOLVER-1564857 firebase-tools@9.17.0 requires pac-resolver@^4.1.0 via a transitive dependency on pac-proxy-agent@4.1.0. upgrading to proxy-agent@5.0.0 causes pac-resolver to get upgraded to 5.0.0, resolving the issue. Co-authored-by: Bryan Kendall <bkend@google.com> * adding externalServices to extensions types (firebase#3766) * fix login:use and account resolution issue (firebase#3773) * Minor fixes for Auth Emulator IDP widget. (firebase#3774) * Minor fixes for Auth Emulator IDP widget. * Changelog. * Move ref parsing code to a separate file. (firebase#3779) * migrating parseRef to ref * moving ref parsing into its own file * add jsdocs * renaming to refs * forgot to save * Generate CloudEvents in the PubSub Emulator (firebase#3767) Update PubSub Emulator to emit events in CloudEvent format given a trigger whose function signature is `cloudevent`. Previously, the Functions Emulator considered 2 types of functions - `https` and `background`. With the introduction of [CloudEvents](https://cloud.google.com/functions/docs/writing/cloudevents) in Google Cloud Functions, we now have 2 types of `background` functions - `legacy` vs `cloudevent`. For example: ```js /* Legacy Events */ exports.helloPubSub = functions.pubsub.topic('topic-name').onPublish((message) => { // ... }); /* CloudEvents */ exports.helloPubSub = functions.v2.pubsub.topic('topic-name').onPublish((cloudevent) => { const message = cloudevent.data.message; }); ``` To accommodate, we adopt concept of "function signature" introduced in Google Cloud Function's [Functions Framework](https://github.com/GoogleCloudPlatform/functions-framework-nodejs) to categorize each function trigger as one of `http`, `event`, or`cloudevent`. When registering a function trigger with the Pubsub emulator, the functions's signature type will be included in the registration request, and the Pubsub emulator will use the info to emit an event in the format expected by the underlying function trigger. We also make minor changes to the Functions Emulator to selectively massage the incoming events in-route to the function trigger. As an added bonus, we are now able to remove `triggerType` field in the `FunctionsRuntimeArg` as that info is now outdated and not needed when invoking an emulated function. * Add Endpoints version of DeploymentPlanner (firebase#3756) * Fork translator implementations * TriggerDiscovery now records Endpoints as well as Specs * Remove debug print * Start moving over existing use cases * Migrate the deploy codebase aside from release code * Migrate deploymentPlanner * Make code easier to review * PR feedback * Start inferring wantBackend details from existingBackend (firebase#3790) * Start inferring wantBackend details from existingBackend * Update src/test/deploy/functions/prepare.spec.ts Co-authored-by: Daniel Lee <danielylee@google.com> Co-authored-by: Daniel Lee <danielylee@google.com> * Adds Fabricator to release code (firebase#3807) * Adds Fabricator to release code Fabricator is the repalcement for the old Tasks codebase, though it will not handle the portion of tracking or error reporting internally (those will be future utilities for better testing). Some differences between tasks.ts and fabricator.ts: * Queues are used for narrow transactions, which means we don't accidentally have an error bubble up and cause a retry on a bulk operation. There's a design pattern of executor.run.catch(rethrowAs) * Function triggers (not EventArc triggers, which are deployed as part of the function, but external triggers like topics, and in the future intents or task queues) are only created after a successful function creation and functions are only deleted after a successful trigger deletion * We do not delete functions if an upsert failed (this helps catch cases where a user renamed a function) * This code is actually unit tested (hooray!) * Delete scratch space code * PR feedback + tests & fixes for SourceTokenScraper * Merge master; backport recent changes (firebase#3816) Merge master; backport @colerogers' changes to Endpoint code. * Add metrics and error reporting to release code (firebase#3815) Adds Fabricator to release code Fabricator is the repalcement for the old Tasks codebase, though it will not handle the portion of tracking or error reporting internally (those will be future utilities for better testing). Some differences between tasks.ts and fabricator.ts: * Queues are used for narrow transactions, which means we don't accidentally have an error bubble up and cause a retry on a bulk operation. There's a design pattern of executor.run.catch(rethrowAs) * Function triggers (not EventArc triggers, which are deployed as part of the function, but external triggers like topics, and in the future intents or task queues) are only created after a successful function creation and functions are only deleted after a successful trigger deletion * We do not delete functions if an upsert failed (this helps catch cases where a user renamed a function) * This code is actually unit tested (hooray!) * Move firebase functions:delete to use Endpoints code (firebase#3821) * Move functions:delete to endpoints code * Remove old functions delete code * Make container contract parsing use Endpoints (firebase#3826) * Inlined.endpoints 9.6.discovery (firebase#3830) * Make container contract parsing use Endpoints * Finish the endpoints refactor! (firebase#3827) * Delete dead code; make a few fixes as I discover them * Free up 12LOC to meet budget * Fixes from bugbashing (firebase#3832) * Don't obscure helpful error messages * Functions should have deployment-tool label and functions:delete shouldn't need it * Lost commit? Record URI after deploys for future printing * Lint fixes * Alternative deploymentTool fix * get rid of extra space in logOpStart * Don't cache trigger regions if the trigger changed * functions list should list ID not entrypoint * Fix compiler erro * Rewrite trigger region copy code * Enablement of APIs should have 'functions' prefix * Remember old trigger region. Recreate Fn when it changes * Run formatter Co-authored-by: Daniel Lee <danielylee@google.com> Co-authored-by: Lisa Jian <lisajian@google.com> Co-authored-by: Yuchen Shi <yuchenshi@google.com> Co-authored-by: joehan <joehanley@google.com> Co-authored-by: Avi Vahl <avi.vahl@wix.com> Co-authored-by: Bryan Kendall <bkend@google.com>

taeold added 11 commits September 20, 2021 19:45

prettify

72fb3bd

Add cloudevent as signature type.

c6cc2b8

Pass signatureType when registering trigger to pubsub.

06b208d

Emit cloudevent from pubsub emulator.

5d822bf

Relay CloudEvent to function trigger.

ddbb9be

Send message data as bas64 encoded string.

5ae01a5

Prettify.

8b9f243

Fill in correct subscription name.

e1145c4

Add testcase for pubsubv2 functions in the e2e test.

718df58

Update version of firebase-functions (with v2 namespace).

d972000

google-cla bot added the cla: yes Manual indication that this has passed CLA. label Sep 21, 2021

Fix import path for functions v2 for node 10

3e1ceb2

taeold changed the title ~~Generate events in CloudEvent format from the PubSub Emulator~~ Generate CloudEvents in the PubSub Emulator Sep 21, 2021

taeold requested review from yuchenshi and abeisgoat September 21, 2021 06:55

taeold marked this pull request as ready for review September 21, 2021 06:55

taeold requested review from inlined and colerogers September 21, 2021 06:56

yuchenshi approved these changes Sep 22, 2021

View reviewed changes

taeold added 4 commits September 21, 2021 19:50

Reorder constants.

1fe2e56

Rename vars appropriate, simplify data structure.

485d922

Fix typo.

22b8549

Fix incorrect log msg.

34ee753

taeold force-pushed the dl-cf3-cloudevents-pubsub branch from 85259ed to 34ee753 Compare September 22, 2021 02:58

Merge branch 'master' into dl-cf3-cloudevents-pubsub

09094b4

inlined reviewed Sep 22, 2021

View reviewed changes

taeold added 2 commits September 23, 2021 00:21

Respond to comments.

ed83f66

Merge branch 'dl-cf3-cloudevents-pubsub' of https://github.com/fireba…

6c433b7

…se/firebase-tools into dl-cf3-cloudevents-pubsub

taeold requested a review from inlined September 24, 2021 16:40

Merge branch 'master' into dl-cf3-cloudevents-pubsub

aa8331f

taeold merged commit 54c822d into master Sep 24, 2021

taeold deleted the dl-cf3-cloudevents-pubsub branch September 24, 2021 20:23

inlined reviewed Sep 27, 2021

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Generate CloudEvents in the PubSub Emulator #3767

Generate CloudEvents in the PubSub Emulator #3767

taeold commented Sep 21, 2021 •

edited

inlined left a comment

inlined Sep 22, 2021

taeold Sep 23, 2021 •

edited

inlined Sep 27, 2021

inlined Sep 22, 2021

taeold Sep 23, 2021

inlined Sep 22, 2021

taeold Sep 23, 2021 •

edited

inlined Sep 27, 2021

inlined Sep 27, 2021

Generate CloudEvents in the PubSub Emulator #3767

Generate CloudEvents in the PubSub Emulator #3767

Conversation

taeold commented Sep 21, 2021 • edited

inlined left a comment

Choose a reason for hiding this comment

inlined Sep 22, 2021

Choose a reason for hiding this comment

taeold Sep 23, 2021 • edited

Choose a reason for hiding this comment

inlined Sep 27, 2021

Choose a reason for hiding this comment

inlined Sep 22, 2021

Choose a reason for hiding this comment

taeold Sep 23, 2021

Choose a reason for hiding this comment

inlined Sep 22, 2021

Choose a reason for hiding this comment

taeold Sep 23, 2021 • edited

Choose a reason for hiding this comment

inlined Sep 27, 2021

Choose a reason for hiding this comment

inlined Sep 27, 2021

Choose a reason for hiding this comment

taeold commented Sep 21, 2021 •

edited

taeold Sep 23, 2021 •

edited

taeold Sep 23, 2021 •

edited