mcpbeat

Verify Local Changes

googleapis/verify local changes

Verifies local Java SDK changes.

844 tokens
context cost
the whole folder, loaded on every use
1
files
instructions only
0
copies elsewhere
how many repositories repackaged it
112
stars on the repo
on the repository, not the skill itself

Install

one command, takes just this skill from the repository
npx skills add https://github.com/googleapis/java-firestore --skill Verify Local Changes

The instruction itself

8 sections, as written by the author

Verify Local Changes

This skill documents how to verify local code changes for the Java Firestore SDK. This should be run every time you complete a fix or feature and are prepared to push a pull request.

Prerequisites

Ensure you have Maven installed and are in the java-firestore directory before running commands.


Step 0: Format the Code

Run the formatter to ensure formatting checks pass:

mvn com.spotify.fmt:fmt-maven-plugin:format

Step 1: Unit Testing (Isolated then Suite)

  • Identify modified unit tests in your changes.
  • Run specific units only to test isolated logic regressions:
    mvn test -Dtest=MyUnitTest#testMethod
  • Run the entire unit test suite that contains those modified tests if the isolated unit tests pass:
    mvn test -Dtest=MyUnitTest

Step 2: Integration Testing (Isolated then Suite)

💡 Integration Test Nuances (from ITBaseTest.java)

When running integration tests, configure your execution using properties or environment variables:

  • FIRESTORE_EDITION:
  • standard (Default)
  • enterprise
  • *Note*: Pipelines can only be run against enterprise editions, while standard Queries run on both.
  • FIRESTORE_DATABASE_ID:
  • Enterprise editions usually require a named database (often enterprise). Adjust this flag if pointing to specific instances.
  • FIRESTORE_TARGET_BACKEND:
  • PROD (Default)
  • QA (points to standard sandboxes)
  • NIGHTLY (points to test-firestore.sandbox.googleapis.com:443)
  • EMULATOR (points to localhost:8080)
  • Identify modified integration tests (usually Starting in IT).
  • Run specific integration tests only (isolated checks run quicker):
    mvn verify -Penable-integration-tests -DFIRESTORE_EDITION=enterprise -DFIRESTORE_DATABASE_ID=enterprise -Dtest=ITTest#testMethod -Dclirr.skip=true -Denforcer.skip=true -fae
  • Run the entire integration test suite for the modified class if isolation tests pass:
    mvn verify -Penable-integration-tests -DFIRESTORE_EDITION=enterprise -DFIRESTORE_DATABASE_ID=enterprise -Dtest=ITTest -Dclirr.skip=true -Denforcer.skip=true -fae

Step 3: Full Suite Regressions

Run the full integration regression suite once you are confident subsets pass:

mvn verify -Penable-integration-tests -DFIRESTORE_EDITION=enterprise -DFIRESTORE_DATABASE_ID=enterprise -Dclirr.skip=true -Denforcer.skip=true -fae

> [!TIP]

> Use -Dclirr.skip=true -Denforcer.skip=true to speed up iterations where appropriate without leaking compliance checks.


🛠️ Troubleshooting & Source of Truth

If you run into issues executing tests with the commands above, consult the Kokoro configuration files as the ultimate source of truth:

  • Presubmit configurations: See .kokoro/presubmit/integration.cfg (or integration-named-db.cfg)
  • Nightly configurations: See .kokoro/nightly/integration.cfg (or integration-named-db.cfg)
  • Build shell scripts: See .kokoro/build.sh

These files define the exact environment variables (e.g., specific endpoints or endpoints overrides) the CI server uses!

How to use it

Copy the folder

Take googleapis/verify local changes from the repository into ~/.claude/skills for personal use, or into .claude/skills inside a project.

Check the name does not clash

The agent identifies a skill by the name field in its header. Two skills with the same name cannot sit side by side — one of them will be ignored.