Update next to match master #9313
Conversation
…onfiguration. (#9300) Co-authored-by: Jamie Rothfeder <rothbutter@google.com>
* feat(dataconnect): add confirmation for Gemini schema generation
Instead of directly asking for an app description to generate a schema with Gemini, this change first asks the user to confirm if they want to use Gemini.
If the user confirms, it then prompts for the app description with a default value of "an app for ${setup.projectId}".
* prompts
* changelog
* m
* feedback
* typo
* metrics
* Update index.ts
---------
Co-authored-by: google-labs-jules[bot] <161369871+google-labs-jules[bot]@users.noreply.github.com>
Summary of ChangesHello @fredzqm, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request primarily focuses on streamlining the handling of the Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a significant refactoring of how the --json flag is handled across the CLI. The new approach standardizes JSON output by using the return value of a command's action, which is a clean and maintainable pattern. This is cleverly enforced by changing the json property on the options type to undefined and providing clear documentation. The changes are applied consistently across numerous commands. I've identified one case where this refactoring causes a functional regression in the JSON output for firestore:backups:list. Additionally, there are some nice UX improvements for firebase init dataconnect.
|
|
||
| // TODO: Consider returning listBackupResponse instead for --json. This will | ||
| // be a breaking change but exposes .unreachable, not just .backups. | ||
| return backups; |
There was a problem hiding this comment.
This change introduces a regression for users of the --json flag. Previously, the full listBackupsResponse object (including the unreachable field) was printed as JSON. With this change, only the backups array is returned, and thus printed, losing the unreachable information for JSON consumers.
While the TODO comment acknowledges this, it would be better to avoid this regression. I suggest returning listBackupsResponse to maintain the existing behavior for JSON output. This would be a breaking change for programmatic users of the command who might rely on the return value being Backup[], but given the new command framework's convention of using the return value for JSON output, it's the more correct and consistent approach.
| return backups; | |
| return listBackupsResponse; |
github-project-automation
bot
moved this to Approved [PR]
in [Cloud] Extensions + Functions
github-project-automation
bot
moved this from Approved [PR]
to Done
in [Cloud] Extensions + Functions
4 participants
No description provided.