Thank you for contributing to the Firebase community!
- Have a usage question?
- Think you found a bug?
- Have a feature request?
- Want to submit a pull request?
- Need to get set up locally?
We get lots of those and we love helping you, but GitHub is not the best place for them. Issues which just ask about usage will be closed. Here are some resources to get help:
- Go through the guides
- Read the full API reference
If the official documentation doesn't help, try asking a question on the Firebase Google Group or one of our other official support channels.
Please avoid double posting across multiple channels!
Yeah, we're definitely not perfect!
Search through old issues before submitting a new issue as your question may have already been answered.
If your issue appears to be a bug, and hasn't been reported, open a new issue. Please use the provided bug report template and include a minimal repro.
If you are up to the challenge, submit a pull request with a fix!
Great, we love hearing how we can improve our products! Share you idea through our feature request support channel.
Sweet, we'd love to accept your contribution! Open a new pull request and fill out the provided template.
If you want to implement a new feature, please open an issue with a proposal first so that we can figure out if the feature makes sense and how it will work.
Make sure your changes pass our linter and the tests all pass on your local machine. Most non-trivial changes should include some extra test coverage. If you aren't sure how to add tests, feel free to submit regardless and ask us for some advice.
Finally, you will need to sign our Contributor License Agreement, and go through our code review process before we can accept your pull request.
Contributions to this project must be accompanied by a Contributor License Agreement. You (or your employer) retain the copyright to your contribution. This simply gives us permission to use and redistribute your contributions as part of the project. Head over to https://cla.developers.google.com/ to see your current agreements on file or to sign a new one.
You generally only need to submit a CLA once, so if you've already submitted one (even if it was for a different project), you probably don't need to do it again.
All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose. Consult GitHub Help for more information on using pull requests.
Install Java 7 or higher. You can also use Java 8, but please note that the Firebase Admin SDK must maintain full Java 7 compatibility. Therefore make sure that you do not use any Java 8 features (e.g. lambdas) when writing code for the Admin Java SDK.
We use Apache Maven for building, testing and releasing the Admin Java SDK code. Follow the installation guide, and install Maven 3.3 or higher.
Maven Checkstyle plugin is configured to run everytime the build is invoked. This plugin verifies source code format, and enforces a number of other Java programming best practices. Any style violations will cause the build to break.
Configuration for the Checkstyle plugin can be found in the checkstyle.xml file at the root of the
repository. To execute only the linter without rest of the build pipeline, execute the following
command:
mvn validate
If you are using Eclipse for development, you can install the
Eclipse Checkstyle plugin, and import the checkstyle.xml
file into the IDE. This enables you to have the linter constantly checking your code as you develop.
A similar plugin is available for
IntelliJ IDEA as well.
Tests are implemented using the Junit4 framework, and are housed under
the src/test subdirectory. They get executed as part of the build, and test failures will cause
the build to break. To run the unit tests without the rest of the build pipeline, execute the
following command:
mvn test
Integration tests are also written using Junit4. They coexist with the unit tests in the src/test
subdirectory. Integration tests follow the naming convention *IT.java (e.g. DataTestIT.java),
which enables the Maven Surefire and Failsafe plugins to differentiate between the two types of
tests. Integration tests are executed against a real life Firebase project, and therefore
requires an Internet connection.
Create a new project in the Firebase console if you do
not already have one. Use a separate, dedicated project for integration tests since the test suite
makes a large number of writes to the Firebase realtime database. Download the service account
private key from the "Settings > Service Accounts" page of the project, and save it as
integration_cert.json at the root of the codebase. Grant your service account the Firebase Authentication Admin role at
Google Cloud Platform Console / IAM & admin. This is
required to ensure that exported user records contain the password hashes of the user accounts.
Also obtain the web API key of the project from the "Settings > General" page, and save it as
integration_apikey.txt at the root of the codebase.
Some of the integration tests require an Identity Platform project with multi-tenancy enabled. An existing Firebase project can be upgraded to an Identity Platform project without losing any functionality via the Identity Platform Marketplace Page. Note that charges may be incurred for active users beyond the Identity Platform free tier.
Now run the following command to invoke the integration test suite:
mvn verify
The above command invokes both unit and integration test suites. To execute only the integration
tests, specify the -DskipUTs flag.
Invoke the Maven Javadoc plugin as follows to generate API docs for all packages in the codebase:
mvn javadoc:javadoc
This will generate the API docs, and place them in the target/site/apidocs directory.
To generate API docs for only the public APIs (i.e. ones that are not marked with @hide tags),
you need to trigger the devsite-apidocs Maven profile. This profile uses Maven Javadoc plugin
with Doclava, which honors the @hide tags in
source code. Dovlava also accepts a set of Clearsilver templates as
a parameter. You can trigger this Maven profile by running the following command:
mvn site -Ddevsite.template=path/to/templates/directory/
This command will place the generated API docs in the target/apidocs directory.