Repository navigation
Conversation
anitdas
force-pushed
the
anitdas/crashlytics-heapdump-commands
branch
4 times, most recently
from
October 2, 2026 15:49
d87c4ce to
2104e09
Compare
- Add crashlytics:heapdumps:enable to check billing, auto-provision GCS bucket with CORS and 90-day file TTL, generate Crashlytics service identity, grant P4SA storage object creator role, and enable Profiling Manager collection. - Add crashlytics:heapdumps:disable to disable heap dump collection. - Add crashlytics:heapdumps:status to query collection status and bucket details. - Implement Profiling Manager API helpers in src/crashlytics/profilingManager.ts. - Add comprehensive unit tests in src/commands/crashlytics-heapdumps.spec.ts and src/crashlytics/profilingManager.spec.ts. # Conflicts: # CHANGELOG.md
- Add 'cors' to fieldMasks doNotRecurseIn list in storage.patchBucket - Instantiate Crashlytics v1 API client lazily via getCrashlyticsV1Client() - Ensure hashedPackageName is lowercased in createBucketName() - Simplify error status extraction in ensureHeapDumpStorageBucket()
anitdas
force-pushed
the
anitdas/crashlytics-heapdump-commands
branch
from
October 2, 2026 16:36
2104e09 to
1018801
Compare
…ingManager.spec.ts
…ers (firebase#11026) ### Description In 2nd-gen Cloud Functions, default region resolution for event-triggered functions (e.g., Firestore or Storage) queries GCP APIs to discover the location of the trigger resource. When these triggers use parameters for event filters (such as `database: defineString("DATABASE")` or `bucket: defineString("BUCKET")`), default region resolution previously failed because parameter evaluation occurred after region resolution. The CLI passed raw CEL expressions (e.g., `"{{ params.DATABASE }}"`) to GCP APIs, causing invalid resource ID errors and silently falling back to deploying in `us-central1`. This regression occurred after PR firebase#10471 moved region resolution ahead of `build.resolveBackend` to support VPC connector formatting. Because `build.resolveBackend` bundled both parameter evaluation and backend conversion, parameter resolution was inadvertently deferred. To fix this: 1. **Lifecycle Hook**: Added an optional `resolveRegions` hook to `build.resolveBackend`. This allows parameter evaluation, default region discovery, and Backend AST generation to execute sequentially in a single pass while keeping `build.ts` hermetic and preserving a clean interface in `prepare.ts`. 2. **Ephemeral Filter Resolution**: During region discovery, `resolveRegionForTrigger` ephemerally resolves filter expressions for the GCP API query without mutating the underlying `Build` AST. Fixes firebase#11020 ### Scenarios Tested - Unit tests in `prepare.spec.ts` for parameterized Firestore and Storage triggers resolving to mapped regions (`europe-west1`) while preserving raw expressions on the `Build` object. - Fallback unit test verifying graceful default to `us-central1` if parameter resolution fails. - Unit test in `build.spec.ts` verifying `build.resolveBackend` executes the `resolveRegions` hook before generating VPC connector paths. - `npm run test` - Manual test using the reproduction case from firebase#11020 ### Sample Commands - `firebase deploy --only functions`
…mmands (firebase#11240) * fix(functions): support function kit instances in functions:lifecycle commands ### Description Use `getCodebasesFromConfig(fnConfig).includes(codebase)` in `loadCodebaseBuild` so that `firebase functions:lifecycle:list` and `firebase functions:lifecycle:run` recognize Function Kit instance IDs defined in `firebase.json`, and pass `[{ codebase }]` to `loadCodebases` so only the targeted codebase or kit instance is built. Fixes b/569972069 ### Scenarios Tested - Added unit test in `src/commands/functions-lifecycle.spec.ts` verifying `loadCodebaseBuild` loads a Function Kit instance build and passes `[{ codebase }]` to `loadCodebases`. ### Sample Commands ```bash firebase functions:lifecycle:list <kit-instance-id> firebase functions:lifecycle:run afterFirstDeploy <kit-instance-id> ``` * Update Changelog format * Use configForCodebase to verify existence and call shouldUseRuntimeConfig on specific codebase
…h nock.disableNetConnect() in mocha-bootstrap.js (firebase#11178) * test: [Task] Block real outbound network in unit tests with nock.disableNetConnect() in mocha-bootstrap.js (b/566321794) * fix(test): only disable outbound network for unit tests, allowing integration test suites to access network * fix(test): re-assert net-connect restrictions in mocha hooks and guard enableNetConnect * fix(test): scope net-connect enforcement per test file and remove env var escape hatch * fix(test): invert condition in enforceNetConnectPolicy for readability * fix(test): remove top-level enforceNetConnectPolicy call
…rebase#11219) * adding cloud trace storage provisioning to crashlytics onboarding * addressing AI comments * adding feature as an experiment * addressing experimental ai review bot feedback
…equests (firebase#11229) * refactor(hosting): use project-scoped endpoints for all Hosting API requests ### Description Firebase Hosting API requests historically supported site-scoped paths (/v1beta1/sites/{site}/...) or project-scoped paths with a - wildcard (/v1beta1/projects/-/sites/{site}/...) due to global site uniqueness. This change eliminates all site-scoped requests and - wildcard project identifiers across the codebase in favor of explicit project-scoped API calls (/v1beta1/projects/{project}/sites/{site}/...): - **src/hosting/api.ts**: - Updated createVersion, updateVersion, listVersions, cloneVersion, and createRelease to accept an explicit project: string parameter and use /projects/${project}/sites/${site}/... - Removed default fallback of project: string | number = "-" from channel APIs (getChannel, listChannels, createChannel, updateChannelTtl, deleteChannel), requiring callers to provide the project ID. - **src/commands/hosting-disable.ts**: - Scoped the release creation to /projects/${projectId}/sites/${siteToDisable}/releases using needProjectId(options). - **src/commands/hosting-clone.ts**: - Eliminated all "-" project wildcards; resolves source and target project IDs from needProjectId(options) or the [<project>:]<site>:<channel> target format. - **src/commands/hosting-channel-deploy.ts**: - Updated version string parsing to match the project-scoped resource name format (projects/${projectId}/sites/${site}/versions/...). - **src/deploy/hosting/prepare.ts & src/deploy/hosting/release.ts**: - Passed context.projectId to all version and release lifecycle functions. - **src/hosting/runTags.ts**: - Passed project to listVersions. - **Tests**: - Added new unit test suites: src/commands/hosting-disable.spec.ts and src/commands/hosting-clone.spec.ts. - Updated existing tests in src/hosting/api.spec.ts, src/deploy/hosting/prepare.spec.ts, and src/deploy/hosting/release.spec.ts. - **CHANGELOG.md**: Added entry documenting project-scoped Hosting API calls. ### Scenarios Tested - **Unit tests**: Passed full fast test suite (npm run mocha:fast, 5,669 passing), covering: - Project-scoped version creation, clone, update, and release API helpers. - Project resolution and error handling for hosting:clone (same-project, cross-project, and invalid targets). - Project resolution and prompt confirmation for hosting:disable. - Deployment preparation and release flows. - **Linting & Formatting**: Passed npm run lint:changed-files (0 errors) and prettier check. - **Manual Verification**: - firebase deploy --only hosting deploys with project-scoped version and release creation. - firebase hosting:channel:create, firebase hosting:channel:list, and firebase hosting:channel:deploy succeed with project-scoped endpoints. - firebase hosting:clone successfully clones channels and tags versions without using "-". - firebase hosting:disable successfully creates the disable release and halts traffic. ### Sample Commands ```bash firebase deploy --only hosting --project <PROJECT_ID> firebase hosting:channel:create <CHANNEL_ID> --project <PROJECT_ID> firebase hosting:channel:deploy <CHANNEL_ID> --project <PROJECT_ID> firebase hosting:clone <SITE_ID>:<SOURCE_CHANNEL> <SITE_ID>:<TARGET_CHANNEL> --project <PROJECT_ID> firebase hosting:disable --site <SITE_ID> --project <PROJECT_ID> ``` * stub configstore * fix(hosting): type options parameter as Options in hosting:clone * fix(hosting): fix typo and eliminate non-null assertions in hosting:clone
…ebase#11093) ### Description Fixes firebase#7755 Functions parameter interpolation previously failed when evaluating nested ternary CEL expressions (e.g., `params.FOO == "a" ? "x" : params.FOO == "b" ? "y" : "z"`). Because the previous implementation relied on greedy regular expressions, the parser latched onto the final `?` and `:` delimiters, incorrectly absorbing intermediate branches into the condition. This caused parameter loading failures or selected the wrong branch. This change replaces the regular expressions with a single-pass, quote-aware depth-counting parser that accurately pairs delimiters across arbitrary nesting depths in both branches. ### Scenarios Tested - Unit tests in `cel.spec.ts` and `params.spec.ts` covering: - Nested ternaries in true, false, and bilateral branches across multiple nesting levels. - Quoted string literals containing `?` and `:` delimiters. - Escaped quotes (`\"`) and list branch expressions. - Type-checking and syntax error handling. - Full test suite (`npm run mocha:fast`) and linter (`npm run lint:changed-files`). ### Sample Commands firebase deploy --only functions firebase emulators:start --only functions
…ase#11243) ### Description Adds comprehensive guidelines to `GEMINI.md` covering code quality, prior art harmonization, TypeScript idioms, CLI architecture, stream discipline, and test mock hygiene that align repository authoring conventions with PR review standards: #### Code Quality & Utilities - **Survey Prior Art & Harmonize Utilities:** Check existing patterns in `src/utils.ts` and relevant subsystems before writing common helpers (retries, backoff, string parsing, path containment, domain transformations); reuse or unify immediately rather than creating diverging parallel implementations. - **Actionable Errors & Exit Codes:** Throw `FirebaseError` with concrete remediation guidance (e.g. expected format, `--force`, or discovery commands) and specify `{ exit: 1 }` for precondition violations. - **Constants & Lookups:** Extract magic numbers, default timeouts, millisecond offsets, and repeated strings to top-level `UPPER_SNAKE_CASE` constants; mark static lookup tables/arrays as `readonly` or `as const`. #### Command Architecture & Lifecycle (`src/command.ts`) - **Thin CLI Commands:** `src/commands/` handles argument parsing, option declaration, and validation only; business logic, multi-step orchestration, and API calls belong in dedicated modules in `src/`. - **Standardized Hooks & Options:** Use `.before()` hooks for prerequisite gating (`requireAuth`, `needProjectId`, `requirePermissions`) and `Command.withForce()` for destructive/confirmable actions. - **Stream Discipline & Machine Composability:** - Route machine-parseable data to `stdout` under `--json`, and interactive spinners (`ora`), diagnostic logs, and warnings to `stderr`. - Stream isolation: never interleave active `ora` spinners with unbuffered `logger.info` or `logLabeledBullet` calls; stop spinners before printing sequential step logs. #### TypeScript Idioms - **Union Types over Enums:** Disallow native TypeScript `enum` in favor of union type literals. - **Iterators & Control Flow:** Prefer `for..of` over `.forEach` for async safety and early returns. - **Function Signatures:** Use options objects for functions accepting >3 parameters. - **Interface Types:** Standardize on `undefined` over `null`; use plain object maps (`Record<string, T>`) or arrays instead of `Map` or `Set` in public interface contracts. #### Testing - **Lifecycle Mock Teardown:** Clean up stubs and network intercepts in `afterEach()` (`sinon.restore()`, `nock.cleanAll()`), never in suite-level `after()`. - **Test Public Interfaces:** Exercise public entry points and exported module functions rather than testing or stubbing private internal helpers. ### Scenarios Tested - `npx prettier --check GEMINI.md` passed cleanly.
…#11202) * Create a basic, initial schema for firebase.json * improve testing * Require region, remove serviceAccount, and register run in Config.KNOWN_PROPS * Remove unused Deployable predeploy/postdeploy from RunSingle * Update shared GCP clients (runv2, run, artifactregistry) * Add defensive optional chaining in run.ts and runv2.ts * Rename masterTimeout option to pollTimeoutMs in runv2 * Make updateMask fallback in updateService more readable * Add comment explaining default updateMask calculation in updateService * Type Service.ingress as IngressTraffic union in runv2 * Format updateMask call with Prettier and guard template literal in runv2
* Add direct_cloud_run experiment flag * Rename direct_cloud_run experiment to directcloudrun
* Add firebase init run interactive setup * Use directcloudrun experiment and validate rootDir is a directory * Trim baseImage input in init run * Improve readability of firebase init run and remove mainContainer * Use dirExistsSync from fsutils in init run promptRootDir * Don't default to a base image in init run A base image turns on automatic base image updates, which are off by default. So init no longer suggests nodejs22. An existing service still defaults to its own base image. * Make upsertRunConfig easier to read Spell out what init changes on an existing service (rootDir and region) instead of merging three spreads. upsertRunConfig now adds the default ignore list itself, so actuate no longer passes it. Behavior is unchanged; added a test for the ignore fallback on existing services. * Don't add an ignore list to an existing service in init run Re-running init on a service that's already in firebase.json filled in the default ignore list when the entry didn't have one. Init doesn't ask about ignore, so it shouldn't change it: an existing entry now only gets the rootDir and region the user just chose. New services still get the default ignore list. * Default init run's root directory to the saved one, matching by service ID and region Pressing Enter now keeps the root directory saved in firebase.json instead of resetting it to /. Cloud Run service IDs are only unique within a region, so entries now match on both; the same ID in another region gets its own entry. * Write firebase.json once, from init, instead of also from init run's actuate Init already writes firebase.json after every feature is set up, so the write in actuate only printed "Wrote configuration info to firebase.json" a second time. Leaving the write to init also means a failed init leaves firebase.json untouched.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.