-
Notifications
You must be signed in to change notification settings - Fork 289
Initial code migration #1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
* Reformatted all source files * Separated unit and integration tests * Added maven checkstyle plugin * Got the basic build and unit tests working * Scrubbed the codebase for private keys, certificates etc.
New files added:
Files removed:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, so I took a crack at reviewing this. It's huge! I honestly don't think it's going to be reasonable to review the source and test files since it's impossible to know what changed. From what I can tell, it was only linting changes and changes required to use new mocked keys. Given that, I think I'm cool with what's in here. But I do have a slight worry about possible minor bugs introduced from the linting changes. Those are going to be pretty difficult to find in this CL. What do you guys think?
@@ -0,0 +1,12 @@ | |||
{ | |||
"type": "service_account", | |||
"project_id": "mock-project-id", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be mock-project-id-owner
? I see you use this in client_x509_cert_url
, but nowhere else in this file. Should we also update client_email
?
@@ -0,0 +1,12 @@ | |||
{ | |||
"type": "service_account", | |||
"project_id": "mock-project-id", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should you add -none
to project_id
and client_email
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you're right about the client_email. project_id can be the same for all users.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the existing way is correct. These credentials are supposed to be for a set of users (with different privileges) on the same project. I've checked that client_email and cert_url fields are different for each user.
@@ -0,0 +1,12 @@ | |||
{ | |||
"type": "service_account", | |||
"project_id": "mock-project-id", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should you add -editor
to project_id
and client_email
?
@schmidt-sebastian once fixed hundreds of lint errors in our Android codebase and to verify the correctness, he and BenWu decompiled the jars and compared the code. Can we do the same thing here? |
Michael, that was an excellent suggestion. I ran a Java binary compatibility checker on 4.1.6 (last release) and the latest build from Github, and uncovered a couple of changes that shouldn't have been made. I'm making the appropriate fixes now. |
I'm attaching the report generated by the binary compatibility checker. After the latest fixes the compatibility level is 98.3%. You can see the report by extracting the attached zip, and opening the file compat_reports/firebase-admin/4.1.6_to_4.1.7-SNAPSHOT/compat_report.html in a web browser. The only reported changes are due to me renaming some type variables. For example types like |
Jacob, take a look at the binary diff report I've attached. I think it shows that there is no noticeable change at the binary level. So I think we should be good to go. We also have reasonable amount of unit tests, all of which passes. Plus, I've been working on porting the legacy integration tests, and most of them work when pointed to Firebase prod. |
This checker (if I understand correctly) checks for changes in the API surface. That is not enough unfortunately. As @mikelehen pointed out, the way we checked this when I cleaned up the code for G4 compatibility was to create jar files and decompile them. Your diff will likely still be considerable since you renamed variables, but I don't think there is any other way. This commit will also break our ability to merge changes from Android directly, but I think that's fine for now. |
I ran another binary diff tool (pkgdiff) which compares compiled class files all the way down to the instructions. According to this tool the difference between v4.1.6 and latest snapshot is 4.3%. I need to run this again on a Linux environment, to be able to see the detailed diff output. Will do that tomorrow. |
Attaching the pkgdiff reports. I'm still sifting through the data. Will report on my findings. File to look for is pkgdiff_reports/firebase-admin/4.1.6_to_4.1.7-SNAPSHOT/changes_report.html |
Here's a diff report between decompiled sources: |
I've gone through the diff report for the decompiled sources. I'm not seeing any changes that can result in API or behavior changes. In general, the reported diff's are due to following reasons:
The only functional diff I saw was in the GaeThreadFactory class, but this is due to a change we merged to the codebase after 4.1.6 release. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I took a look at the latest diff report you generated and it looked like there was feature parity between the old and new and it's comforting that all our test suites pass. I do think someone like @schmidt-sebastian with some more Java background should take a look to triple check this though before we merge it in.
I spot checked a fair number of files in X_to_Y and the diff looks good to me. Thanks for being so thorough! |
It's quite a few commits, but this is the gist of it:
To run the linter by itself: mvn validate
To run unit tests only: mvn test
To run unit and integration tests: mvn verify -Dfirebase.it.certificate={PathToCertFile} -Dfirebase.it.url={FirebaseDbUrl}