correctly get firestore rules

[aalej]

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

const release = releases.find((r) => r.name.startsWith(prefix));

to

const release = releases.find((r) => r.name === releaseName);

Not sure why we did startsWith
Note:
the getLatestRulesetName method is shared by storage and firestore, so test both
it's only used in rulesDeploy, so test that as well

TODO (FIRESTORE TESTING):

• Test on a project that does not have Firestore
  • Creates rules file with the default template
• Test on a project with 1 Firestore database, the (default) one. Should get the (default) rules
  • Correctly pulls the rules

downloaded rules

rules_version='2'

// this is the updated rules for this database aalej-9829 \(default\)

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if request.time < timestamp.date(2026, 3, 1);
    }
  }
}

• Test on a project with 1 Firestore database, the (default) one. Deployment updates the rules for the (default) database

• Test on a project with multiple Firestore named databases
  • Should get the rules for the selected database

TODO (STORAGE TESTING):

• Test on a project that does not have Storage
  • Errors out and asks user to set up storage(requires billing), after set up, able to pull rules
• Test on a project that has 1 Storage bucket
  • Gets rules from the "default" bucket

downloaded rules

rules_version = '2';

// Craft rules based on data in your Firestore database
// allow write: if firestore.get(
//    /databases/(default)/documents/users/$(request.auth.uid)).data.isAdmin;

// rules for `aalej-9829.firebasestorage.app`

service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if false;
    }
  }
}

• Test on a project with 1 Storage bucket. Deployment updates the rules for the "default" bucket

• Test on a project that has multiple Storage buckets
  • Should get rules from the default bucket

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

Sample Commands

[gemini-code-assist]

Summary of Changes

Hello @aalej, I'm Gemini Code Assist¹! 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

• Precise Release Name Matching: The logic for identifying the latest Firestore ruleset has been updated from a startsWith comparison to an exact === match for release names, ensuring more accurate rule retrieval.
• Database ID Support for Rules Retrieval: The function getRulesFromConsole now accepts a databaseId parameter, allowing for the correct fetching of security rules for specific Firestore databases, including handling the special case of the "(default)" database.

🧠 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 Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

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

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

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.

[gemini-code-assist]

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.

Suggested change

	let releaseName = `projects/${projectId}/releases/${service}`;
	if (resourceName) {
	prefix += `/${resourceName}`;
	releaseName += `/${resourceName}`;
	}
	const releaseName = `projects/${projectId}/releases/${service}${resourceName ? `/${resourceName}` : ""}`;

[aalej]

this seems kinda hard to read? but definitely open to making the change if it improves the codebase

[gemini-code-assist]

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.

Suggested change

	const name = await gcp.rules.getLatestRulesetName(projectId, "cloud.firestore", resourceName);
	const name = await gcp.rules.getLatestRulesetName(projectId, RulesetServiceType.CLOUD_FIRESTORE, resourceName);