Estimate on availability of Scheduled functions in v2 public preview

[Asko Kauppi]

I'm moving a code base from Firebase Cloud Functions v1 to v2 and need to add one scheduled function.

Documentation clearly states that Cloud Functions v2 "does not currently support [...] scheduled functions".  However, the namespace `functions/v2/scheduler` is already there, in latest firebase-functions 4.0.1.

It would help me to know, whether I can expect actual functionality within weeks, or if it will take longer.

Thank you!

[Thomas Bouldin]

It looks like some documentation is out of date and should be fixed. If you update to the latest version of firebase-tools and firebase-functions you should have v2 scheduled function support.

Also, FWIW, you don't need to migrate a whole codebase at a time. We support intermingling v1 and v2 functions in the same codebase.

Thanks,

--Thomas

[Asko Kauppi]

>If you update to the latest version of firebase-tools and firebase-functions you should have v2 scheduled function support.

Great news!

In that case, I'll continue with a comment from my sources:

* v2 'onSchedule' (as of 27-Oct-22) lacks these options (that Cloud Task options has):

*   <<
*     maxInstances: 1,    // make sure that tasks should never run in parallel: important for moving the "marker"
*     concurrency: 1,
*
*     cpu: 0.5,   // (what would be the default, here???)
*     memory: '512MiB',
*
*     region: region_v2,
*
*     secrets: ["METRICS_API_KEY"]      // tbd. when would we use a secret like so?  Where is it placed?????
*   <<
*

I would like to:

- be able to decide where the scheduled function runs (region)

- be able to feed it a secret (secrets)

- be able to advice, how powerful job I'm thinking of running (cpu, memory)

- be able to restrict to just one simultaneous job, even if the earlier one takes longer than intended

With `firebase-functions` 4.0.1, `ScheduleOptions` does not provide these. Is there a way?

- asko

[Thomas Bouldin]

ScheduleOptions inherits GlobalOptions, which includes all those fields. You can use those fields exactly as you used them in your comments. We also added support for params in 4.0. You can now say `defineSecret("METRICS_API_KEY")` and it will inform the CLI that this codebase depends on a secret called METRICS_API_KEY. The CLI will prompt for the value of your secret on any deploy to a project where that secret has not been set up yet.

Also, since you're explicitly avoiding concurrency you might want to set cpu to `gcf_gen1`. That will bring you to the same CPU (and thus price) as v1 in exchange for losing concurrency support.

--
You received this message because you are subscribed to a topic in the Google Groups "Firebase Google Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firebase-talk/vopgpPCphog/unsubscribe.
To unsubscribe from this group and all its topics, send an email to firebase-tal...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/1e9b77c7-cec6-4057-9dee-f2b05413cfcan%40googlegroups.com.