Conversation
Summary of ChangesHello @aalej, 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 refines the mechanism for retrieving Firestore security rules, primarily by correcting the method used to match release names and by introducing support for specifying the target database. These changes aim to ensure that the correct security rules are consistently fetched from the Firebase console, particularly for projects utilizing multiple Firestore databases or when the release naming convention requires an exact match. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. 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
|
There was a problem hiding this comment.
Code Review
This pull request fixes a bug in how Firestore rulesets are retrieved by changing from a potentially incorrect startsWith check to a strict === comparison. It also adds support for fetching rules for named Firestore databases, not just the default one. The changes look correct and improve the reliability of fetching rules. I've added a couple of suggestions to further improve code quality by using const where possible and replacing a magic string with an existing enum for better consistency.
| let releaseName = `projects/${projectId}/releases/${service}`; | ||
| if (resourceName) { | ||
| prefix += `/${resourceName}`; | ||
| releaseName += `/${resourceName}`; | ||
| } |
There was a problem hiding this comment.
For improved immutability and conciseness, you can declare releaseName as a const and construct it in a single expression using a template literal and a ternary operator.
| let releaseName = `projects/${projectId}/releases/${service}`; | |
| if (resourceName) { | |
| prefix += `/${resourceName}`; | |
| releaseName += `/${resourceName}`; | |
| } | |
| const releaseName = `projects/${projectId}/releases/${service}${resourceName ? `/${resourceName}` : ""}`; |
There was a problem hiding this comment.
this seems kinda hard to read? but definitely open to making the change if it improves the codebase
| // A named database would have a resource name, and the releases.name looks like: | ||
| // projects/{project_id}/releases/cloud.firestore/{database_id} | ||
| const resourceName = databaseId === "(default)" ? undefined : databaseId; | ||
| const name = await gcp.rules.getLatestRulesetName(projectId, "cloud.firestore", resourceName); |
There was a problem hiding this comment.
To avoid using a magic string and to improve consistency with other parts of the codebase (like in deploy/firestore), consider using the RulesetServiceType.CLOUD_FIRESTORE enum value instead of the hardcoded string "cloud.firestore". You'll need to import RulesetServiceType from ../../../rulesDeploy.
| const name = await gcp.rules.getLatestRulesetName(projectId, "cloud.firestore", resourceName); | |
| const name = await gcp.rules.getLatestRulesetName(projectId, RulesetServiceType.CLOUD_FIRESTORE, resourceName); |
Description
Fixes #7981
Scenarios Tested
Did some basic testing, but I'll do another round of testing for this just to be thorough since I'm a bit worried about this specific change
this
to
edit: Done with thorough testing, see manual test cases below
Not sure why we did
startsWithNote:
the
getLatestRulesetNamemethod is shared by storage and firestore, so test bothit's also used in
rulesDeploy, so test deployments as wellTODO (FIRESTORE TESTING):
downloaded rules
(default)database"(default)" database selected
"non-default" database selected
"another-database" database selected
(default) database

non-default database

another-database database

TODO (STORAGE TESTING):
downloaded rules
"default" bucket
"default" aalej-9829.firebasestorage.app bucket
aalej-9829-another-bucket

aalej-9829-non-default-bucket
REST API Refs
https://firebase.google.com/docs/reference/rules/rest/v1/projects.releases#Release
https://firebase.google.com/docs/reference/rules/rest/v1/projects.releases/list#response-body
https://docs.cloud.google.com/firestore/docs/reference/rest/v1beta1/projects.databases.indexes/list (not really used)
Sample Commands