Closed jankeromnes closed 6 years ago
I published an offending patch to staging at https://phabricator-dev.allizom.org/D324
Nothing happened. Further troubleshooting is needed to discover if the bot actually detected this new code review or not.
Also, I've never received an email report where the subject includes "New Static Analysis Phabricator", so I suspect that either (1) Phabricator code reviews are never detected by our bot, or (2) some error happens before an email report can be sent.
We could try to run the bot locally to see if there are errors during analysis, but I don't know how to troubleshoot if the hook works.
We could try to run the bot locally to see if there are errors during analysis, but I don't know how to troubleshoot if the hook works.
We can look at the Heroku logs for shipit-staging-pulse-listener, it logs when it starts tasks from Phabricator or MozReview, and then we can see the logs for the task on Taskcluster.
So, I ran the bot manually against the staging patch using the following commands:
$ ./please shell shipit-static-analysis --taskcluster-client-id="mozilla-auth0/ad|Mozilla-LDAP|jkeromnes/static-analysis-dev" --taskcluster-access-token="$TOKEN"
[nix-shell:/app/src/shipit_static_analysis]$ export PHABRICATOR="324:PHID-DIFF-y3axo2xumikkf5chiivb"
[nix-shell:/app/src/shipit_static_analysis]$ mkdir -p /app/tmp
[nix-shell:/app/src/shipit_static_analysis]$ shipit-static-analysis --taskcluster-secret=repo:github.com/mozilla-releng/services:branch:staging --cache-root=/app/tmp
It successfully published a review to https://phabricator-dev.allizom.org/D324, so we can conclude that the bot is able to submit reviews.
However, since it didn't do that automatically, I suspect that the Phabricator hook doesn't trigger on staging (maybe that's specific to staging, or our hook is broken; I'm not sure).
Additionally, you can see in the review that only clang-format
and flake8
issues were published. No eslint
and no clang-tidy
issues were detected, which looks like a big regression. I'll update our top comment so that we keep track of this.
With @marco-c we spied on the Phabricator staging hook to see if it actually triggers if I send a rebased patch up for review.
A task does get triggered, but somehow it says the revision is 622:PHID-DIFF-i4b753ptojloi2tjwm2z
while we expect it to start with 324
(there is no such https://phabricator-dev.allizom.org/D622 because 622
is a "diff ID" and not a "revision ID").
There seems to be a confusion between the latest "diff ID" 622
(there can be many diffs per revision) and the "revision ID" 324
(found in the URL).
This causes analysis to succeed (it only uses the PHID) but then posting the comments fail, because there is no revision 622:
We can either:
shipit-pulse-listener
to give a "revision ID" (324
) instead of the latest "diff ID" (622
)shipit-static-analysis
to take in an actual "diff ID" instead of a "revision ID" as expected todaySo, running shipit-static-analysis
a second time with:
export PHABRICATOR="324:PHID-DIFF-i4b753ptojloi2tjwm2z"
shipit-static-analysis --taskcluster-secret=repo:github.com/mozilla-releng/services:branch:staging --cache-root=/app/tmp
Successfully published new comments against the latest diff. I conclude that shipit-static-analysis
doesn't need the "diff ID" (622), but just the "revision ID" (324).
Let's fix shipit-pulse-listener
.
The phabricator hook parameter issue should be fixed by 3b247846c3f8dae80532aa671421d2df96e241f5. Hopefully auto-reviews will now work on staging, allowing us to move on to review validation.
Now automatically published reviews on staging! :tada: Thanks @marco-c and @garbas for the help, and especially @La0 for writing all the code! :stuck_out_tongue:
Latest review on https://phabricator-dev.allizom.org/D324 was automatically submitted by the bot after I pushed a new revision, and you should have received an email titled:
[staging] New Static Analysis Phabricator #645 - PHID-DIFF-y5cvex4pzvr6g4epqf3g
Edit: FYI successful triggered task was https://tools.taskcluster.net/groups/Zl9BpvZYR0GbkOobShA1pg/tasks/Zl9BpvZYR0GbkOobShA1pg/runs/0/logs/public%2Flogs%2Flive.log
Ok, in the latest review (which was automated), we appear to have eslint
comments now, but still no clang-tidy
.
The staging configuration looks like this:
shipit-static-analysis:
[...]
PUBLICATION: BEFORE_AFTER
[...]
ANALYZERS:
- clang-tidy
- clang-format
- mozlint
From the logs, it looks like clang-tidy did run, but it's hard to tell exactly what happened (partly because clang-format adds a lot of noise).
Relevant log excerpts:
shipit_static_analysis.workflow: Run ClangTidy
shipit_static_analysis.clang.tidy: Available clang-tidy checks:
[... a lot of checkers]
shipit_static_analysis.clang.tidy: Running static-analysis (cmd='gecko-env ./mach --log-no-times static-analysis check --header-filter=scroll.js|.arcconfig|prep_cif.c|menus.js|jsapi.cpp|gen_event_data.py|definitions.js --checks=-*,misc-forward-declaration-namespace,clang-analyzer-deadcode.DeadStores,clang-analyzer-security.FloatLoopCounter,clang-analyzer-security.insecureAPI.UncheckedReturn,clang-analyzer-security.insecureAPI.getpw,clang-analyzer-security.insecureAPI.mkstemp,clang-analyzer-security.insecureAPI.mktemp,clang-analyzer-security.insecureAPI.rand,clang-analyzer-security.insecureAPI.strcpy,clang-analyzer-security.insecureAPI.vfork,misc-argument-comment,misc-assert-side-effect,misc-suspicious-missing-comma,misc-suspicious-semicolon,misc-unused-using-decls,modernize-avoid-bind,modernize-loop-convert,modernize-raw-string-literal,modernize-redundant-void-arg,modernize-shrink-to-fit,modernize-use-equals-default,modernize-use-equals-delete,modernize-use-nullptr,modernize-use-override,mozilla-*,performance-for-range-copy,performance-inefficient-string-concatenation,performance-inefficient-vector-operation,performance-type-promotion-in-math-fn,performance-unnecessary-copy-initialization,performance-unnecessary-value-param,readability-container-size-empty,readability-else-after-return,readability-misleading-indentation,readability-redundant-control-flow,readability-redundant-smartptr-get,readability-redundant-string-cstr,readability-redundant-string-init,readability-uniqueptr-delete-release,modernize-use-auto,modernize-use-bool-literals devtools/client/shared/scroll.js .arcconfig js/src/ctypes/libffi/src/prep_cif.c devtools/client/menus.js js/src/jsapi.cpp toolkit/components/telemetry/gen_event_data.py devtools/client/definitions.js')
+ exec ./mach --log-no-times static-analysis check '--header-filter=scroll.js|.arcconfig|prep_cif.c|menus.js|jsapi.cpp|gen_event_data.py|definitions.js' '--checks=-*,misc-forward-declaration-namespace,clang-analyzer-deadcode.DeadStores,clang-analyzer-security.FloatLoopCounter,clang-analyzer-security.insecureAPI.UncheckedReturn,clang-analyzer-security.insecureAPI.getpw,clang-analyzer-security.insecureAPI.mkstemp,clang-analyzer-security.insecureAPI.mktemp,clang-analyzer-security.insecureAPI.rand,clang-analyzer-security.insecureAPI.strcpy,clang-analyzer-security.insecureAPI.vfork,misc-argument-comment,misc-assert-side-effect,misc-suspicious-missing-comma,misc-suspicious-semicolon,misc-unused-using-decls,modernize-avoid-bind,modernize-loop-convert,modernize-raw-string-literal,modernize-redundant-void-arg,modernize-shrink-to-fit,modernize-use-equals-default,modernize-use-equals-delete,modernize-use-nullptr,modernize-use-override,mozilla-*,performance-for-range-copy,performance-inefficient-string-concatenation,performance-inefficient-vector-operation,performance-type-promotion-in-math-fn,performance-unnecessary-copy-initialization,performance-unnecessary-value-param,readability-container-size-empty,readability-else-after-return,readability-misleading-indentation,readability-redundant-control-flow,readability-redundant-smartptr-get,readability-redundant-string-cstr,readability-redundant-string-init,readability-uniqueptr-delete-release,modernize-use-auto,modernize-use-bool-literals' devtools/client/shared/scroll.js .arcconfig js/src/ctypes/libffi/src/prep_cif.c devtools/client/menus.js js/src/jsapi.cpp toolkit/components/telemetry/gen_event_data.py devtools/client/definitions.js
I'm not sure what happened, as all analysis steps seem to be running in random order, I guess before and after the patch.
Maybe the problem is related to the BEFORE_AFTER
behavior? I'll try to dig further in the email report soon, but I'm afraid that it is truncated because there are way too many clang-format
comments.
Maybe we could temporarily disable clang-format
on staging to better understand what's happening?
By using #1209, i now get the following issues:
[warning] readability-else-after-return js/src/ctypes/libffi/src/prep_cif.c 88:3
[error] mozilla-dangling-on-temporary js/src/jsapi.cpp 131:39
[error] mozilla-dangling-on-temporary js/src/jsapi.cpp 132:38
[warning] modernize-redundant-void-arg js/src/jsapi.cpp 243:42
[warning] modernize-redundant-void-arg js/src/jsapi.cpp 647:29
[warning] modernize-raw-string-literal js/src/jsapi.cpp 1770:32
[warning] modernize-use-auto js/src/jsapi.cpp 3277:5
[warning] modernize-use-equals-default js/src/jsapi.cpp 3903:5
[warning] modernize-use-equals-default js/src/jsapi.cpp 3906:5
[warning] modernize-use-equals-default js/src/jsapi.cpp 5819:35
[warning] modernize-use-equals-default js/src/jsapi.cpp 7076:15
[warning] modernize-use-equals-default js/src/jsapi.cpp 7080:15
[warning] modernize-redundant-void-arg js/src/jsapi.cpp 7908:15
eslint issue error devtools/client/shared/scroll.js line 7
eslint issue error devtools/client/menus.js line 31
eslint issue error devtools/client/menus.js line 41
eslint issue error devtools/client/definitions.js line 7
flake8 issue error toolkit/components/telemetry/gen_event_data.py line 37
flake8 issue error toolkit/components/telemetry/gen_event_data.py line 37
flake8 issue error toolkit/components/telemetry/gen_event_data.py line 37
flake8 issue error toolkit/components/telemetry/gen_event_data.py line 57
So, our bot seems to catch all the issues again (on staging), which is great.
However, yesterday's push to Phabricator staging didn't get any review comments.
I attempted another push today, watching the logs. I did find a bug with the email report (#1210), but his time the Phabricator comments did work. Maybe it's a race condition, but I guess we'll have to try again a few times to make sure it works consistently.
Now testing on a new phabricator-dev revision: https://phabricator-dev.allizom.org/D431
Triggered analysis task: https://tools.taskcluster.net/groups/DFq61B7ISwaYdCYqUc6QCw/
Last try didn't post any clang-tidy
comments. Let's see if this one does.
EDIT: It worked!
I have a few nits about the automated review that was published to D431 (using the BEFORE_AFTER
heuristic):
codespell
readability-else-after-return
(supposedly enabled)misc-suspicious-missing-comma
(supposedly enabled)readability-misleading-indentation
(supposedly enabled)clang-analyzer-security.FloatLoopCounter
(supposedly enabled)clang-analyzer-security.insecureAPI.UncheckedReturn
(supposedly enabled)clang-analyzer-security.insecureAPI.gets
(not enabled?!)misc-suspicious-semicolon
(supposedly enabled)modernize-redundant-void-arg
(supposedly enabled)clang-analyzer-deadcode.DeadStores
(supposedly enabled)performance-faster-string-find
(not enabled?!)performance-implicit-conversion-in-loop
(not enabled?!)BEFORE_AFTER
bug, see #1236):
modernize-raw-string-literal
modernize-use-equals-default
* 510 issues were found before applying the patch, as we are running with new BEFORE_AFTER
mode on staging:
Mach static analysis found some issues (nb=10)
Skipping clang-diagnostic-error: [error] clang-diagnostic-error js/src/ctypes/libffi/include/ffi_common.h 23:12
Found 3rd party code issue [warning] readability-else-after-return js/src/ctypes/libffi/src/prep_cif.c 88:3
Found in-tree code issue [warning] modernize-redundant-void-arg js/src/jsapi.cpp 608:29
Found in-tree code issue [warning] modernize-raw-string-literal js/src/jsapi.cpp 1675:32
Found in-tree code issue [warning] modernize-use-auto js/src/jsapi.cpp 3190:5
Found in-tree code issue [warning] modernize-use-equals-default js/src/jsapi.cpp 3816:5
Found in-tree code issue [warning] modernize-use-equals-default js/src/jsapi.cpp 3819:5
Found in-tree code issue [warning] modernize-use-equals-default js/src/jsapi.cpp 5732:35
Found in-tree code issue [warning] modernize-use-equals-default js/src/jsapi.cpp 6989:15
Found in-tree code issue [warning] modernize-use-equals-default js/src/jsapi.cpp 6993:15
Found in-tree code issue [warning] modernize-redundant-void-arg js/src/jsapi.cpp 7821:15
Skipping clang-diagnostic-error: [error] clang-diagnostic-error obj-x86_64-pc-linux-gnu/dist/system_wrappers/cstddef 3:15
The codespell error is not in the dictionary (depandent)
I created a PR https://github.com/codespell-project/codespell/pull/549 for the depandent thing
Thanks! But I just made it up, because I didn't know there was a misspelling dictionary (I thought it was Levenstein distance against an actual dictionary).
I don't think that "depandent" is a typo that people could actually make by mistake.
I'll be working on the other issues this week, i'll update this ticket when i get some code
Thanks @La0! Please ping me if I can help. :slightly_smiling_face:
The review summary is generated by Phabricator, we only push the same comment as on Mozreview, without any extra infos about issues.
The differential.createcomment is used to publish these comments.
I just looked at the Phabricator source code, and it seems we could specify an action based on the analysis result :
The request_review & reject seem interesting for our use case
I published a test review from my local version fixing the offset lines + bug report link
The request_review & reject seem interesting for our use case
Indeed, thanks!
reject
reviews, as that may be perceived as harsh (many reviewers often avoid using r-
on a patch, and prefer clearing the review request instead).request_review
flag, because the developer may still want the requested person to have a look (e.g. a patch "[WIP] please comment on my general approach" may have lint issues, but the developer definitely still wants a human to take a look).I published a test review from my local version fixing the offset lines + bug report link
Thanks a lot! The bug report link looks good, but the comments still seem off by one line (e.g. the first eslint: space-infix-ops
issue should be on line 7, but the latest comment is still on lines 7 & 8). Maybe we could ping the Conduit folks about this (and they may or may not forward it via our paid Phabricator support account).
EDIT: Oh, wait, my mistake, the "latest comment" I mention is actually an older comment (from the "BastienAbadie" bot, against the latest diff). The actual "latest comment" was posted by the "ReviewBot" bot, against an old diff (so it appears grey instead of orange), and the off-by-one issue is actually fixed there. So, thanks! :tada:
Thanks for merging the fixes!
But this issue is not quite done yet. (I'll close it when we've enabled Phabricator in production.)
Sorry @jankeromnes, I did not want to close this issue, i used refs
instead of closes
thinking that would do the trick. There is indeed some work left !
No worries! I think GitHub's heuristic triggered on the word "Fixes", followed by an issue number (regardless of the text in between). :stuck_out_tongue:
In the TaskCluster staging secrets, I changed PUBLICATION:
from BEFORE_AFTER
to IN_PATCH
, in order to use what production will use soon.
I then uploaded a new diff to https://phabricator-dev.allizom.org/D324, attempting to re-trigger the bot (with new staging code and IN_PATCH
).
However, the new task https://tools.taskcluster.net/groups/AO98K3mTTJOKBLNQBMUyLA instantly failed with: AssertionError: Specify a phabricator XOR mozreview parameters
.
EDIT: I'll restart the staging pulse listener, as maybe some code changed and I think you need to restart the dynos for changes to take effect.
EDIT 2: No dice, same error. Will try to fix it.
:warning: It turns out that there are several commits on staging
that are not on master
: https://github.com/mozilla-releng/services/compare/staging?expand=1
@La0 I would like to trigger a staging run of shipit-static-analysis
, but it fails now. Could you please help me run another validation run? (on phabricator, with the exact code that will go to production tomorrow, and the correct staging configuration that also looks like production)
I've force-pushed master
to staging
again, and I'm waiting for shipit-static-analysis
to finish building before triggering another Phabricator analysis.
shipit-static-analysis
and shipit-pulse-listener
were successfully built and deployed to staging, and I triggered another analysis.
This time the task went on longer, but it failed in the first ./mach configure
with:
0:53.84 Reticulating splines...
0:54.52 Traceback (most recent call last):
0:54.52 File "/cache/sa-central/configure.py", line 123, in <module>
0:54.52 sys.exit(main(sys.argv))
0:54.52 File "/cache/sa-central/configure.py", line 34, in main
0:54.52 return config_status(config)
0:54.52 File "/cache/sa-central/configure.py", line 118, in config_status
0:54.52 return config_status(args=[], **encode(sanitized_config, encoding))
0:54.52 File "/cache/sa-central/python/mozbuild/mozbuild/config_status.py", line 143, in config_status
0:54.52 definitions = list(definitions)
0:54.52 File "/cache/sa-central/python/mozbuild/mozbuild/frontend/emitter.py", line 171, in emit
0:54.52 for out in output:
0:54.52 File "/cache/sa-central/python/mozbuild/mozbuild/frontend/reader.py", line 880, in read_topsrcdir
0:54.52 for r in self.read_mozbuild(path, self.config):
0:54.52 File "/cache/sa-central/python/mozbuild/mozbuild/frontend/reader.py", line 1047, in read_mozbuild
0:54.52 raise bre
0:54.52 mozbuild.frontend.reader.BuildReaderError:
0:54.52 ==============================
0:54.52 FATAL ERROR PROCESSING MOZBUILD FILE
0:54.52 ==============================
0:54.52
0:54.52 The error occurred while processing the following file:
0:54.52
0:54.52 /cache/sa-central/toolkit/library/rust/gkrust-features.mozbuild
0:54.52
0:54.52 This file was included as part of processing:
0:54.52
0:54.52 /cache/sa-central/toolkit/library/gtest/rust/moz.build
0:54.52
0:54.52 A moz.build file called the error() function.
0:54.52
0:54.52 The error it encountered is:
0:54.52
0:54.52 Builds on automation must use a version of rust that supports OOM hooking
0:54.52
0:54.52 Correct the error condition and try again.
0:54.52
1:06.46 *** Fix above errors and then restart with\
1:06.46 "/nix/store/lhp5rw0dagi5mgqwr9i3x41240ba4ypz-gnumake-4.2.1/bin/make -f client.mk build"
1:06.46 make: *** [client.mk:127: configure] Error 1
For historical purposes: the problem was that we were using a version of Rust (1.27.0) which is not supported for automation on mozilla-central. We were not pinning Rust, so we inadvertently updated from 1.26.2 to 1.27.0 (this is now fixed by https://github.com/mozilla-releng/services/pull/1238).
Updates:
automation && Rust !== 1.27
assert.EDIT: My workaround failed, because even with the IN_PATCH
algorithm, shipit-static-analysis
runs ./mach configure
before applying the patch, not after. So I'm giving up on the workaround. I pushed the #1238 fix to staging, and now I'm waiting for a full redeployment.
Thanks to Bastien's fix, I was finally able to run another analysis on staging (https://tools.taskcluster.net/groups/Y0GiPYNEQHeSwRZ4x0RFoA/), and the bot posted a new review to https://phabricator-dev.allizom.org/D324.
From what I see, it reveals the following problems (with the IN_PATCH
heuristic):
mozilla-*
ones)./mach static-anlaysis check
bug, so not related to our bot):
readability-else-after-return
(supposedly enabled)js/src/ctypes/libffi/src/prep_cif.c
is now considered Third Party)misc-suspicious-missing-comma
(supposedly enabled)readability-misleading-indentation
(supposedly enabled)clang-analyzer-security.FloatLoopCounter
(supposedly enabled)clang-analyzer-security.insecureAPI.UncheckedReturn
(supposedly enabled)misc-suspicious-semicolon
(supposedly enabled)modernize-redundant-void-arg
(supposedly enabled)publish: !!bool no
)clang-analyzer-deadcode.DeadStores
(supposedly enabled)performance-faster-string-find
(supposedly enabled now)eslint: strict
codespell
("maching")js/src/ctypes/libffi/src/prep_cif.c
is still Third Party)BEFORE_AFTER
bug (i.e. #1236)Here is a snippet from the task's debug log:
shipit_static_analysis.report.debug: Debug revision (rev='Phabricator #686 - PHID-DIFF-ocahda37wlvf4mcnyt7n')
shipit_static_analysis.report.debug: Issue silent (issue='[warning] readability-else-after-return js/src/ctypes/libffi/src/prep_cif.c 88:3')
shipit_static_analysis.report.debug: Issue publishable (issue='[error] mozilla-dangling-on-temporary js/src/jsapi.cpp 132:39')
shipit_static_analysis.report.debug: Issue publishable (issue='[error] mozilla-dangling-on-temporary js/src/jsapi.cpp 133:38')
shipit_static_analysis.report.debug: Issue silent (issue='[warning] modernize-redundant-void-arg js/src/jsapi.cpp 244:42')
shipit_static_analysis.report.debug: Issue silent (issue='[warning] modernize-redundant-void-arg js/src/jsapi.cpp 648:29')
shipit_static_analysis.report.debug: Issue silent (issue='[warning] modernize-raw-string-literal js/src/jsapi.cpp 1715:32')
shipit_static_analysis.report.debug: Issue silent (issue='[warning] modernize-use-auto js/src/jsapi.cpp 3204:5')
shipit_static_analysis.report.debug: Issue silent (issue='[warning] modernize-use-equals-default js/src/jsapi.cpp 3830:5')
shipit_static_analysis.report.debug: Issue silent (issue='[warning] modernize-use-equals-default js/src/jsapi.cpp 3833:5')
shipit_static_analysis.report.debug: Issue silent (issue='[warning] modernize-use-equals-default js/src/jsapi.cpp 5746:35')
shipit_static_analysis.report.debug: Issue silent (issue='[warning] modernize-use-equals-default js/src/jsapi.cpp 7006:15')
shipit_static_analysis.report.debug: Issue silent (issue='[warning] modernize-use-equals-default js/src/jsapi.cpp 7010:15')
shipit_static_analysis.report.debug: Issue silent (issue='[warning] modernize-redundant-void-arg js/src/jsapi.cpp 7838:15')
shipit_static_analysis.report.debug: Issue silent (issue='eslint issue error devtools/client/menus.js line 31')
shipit_static_analysis.report.debug: Issue publishable (issue='eslint issue error devtools/client/menus.js line 42')
shipit_static_analysis.report.debug: Issue publishable (issue='flake8 issue error toolkit/components/telemetry/gen_event_data.py line 37')
shipit_static_analysis.report.debug: Issue publishable (issue='flake8 issue error toolkit/components/telemetry/gen_event_data.py line 37')
shipit_static_analysis.report.debug: Issue publishable (issue='flake8 issue error toolkit/components/telemetry/gen_event_data.py line 37')
shipit_static_analysis.report.debug: Issue publishable (issue='flake8 issue error toolkit/components/telemetry/gen_event_data.py line 57')
shipit_static_analysis.report.debug: Issue publishable (issue='eslint issue error devtools/client/shared/scroll.js line 7')
shipit_static_analysis.report.debug: Issue publishable (issue='eslint issue error devtools/client/definitions.js line 7')
Some comments regarding 'misc-suspicious-missing-comma'. It didn't work because the initialiser list is < 5. This can be seen here. if the list would have contained another field, this would have worked, of course this can customised by having a .clang-tidy file in the root but in the mean time let's use an official example from here.
Thanks a lot @abpostelnicu for figuring out the threshold! I've updated the list of undetected checks.
Still, the checks that are not strikethrough should have reported defects in the patch. I'm not sure why the bot only reported mozilla-*
defects.
I've updated our various checklists in this bug. Looking good! Thanks everyone for the hard work.
Now we only need to run analysis on staging one more time (I expect it to be the last), and then move on to validating production (which should take much less time hopefully).
@La0 please ping me when staging is un-broken again, so I can re-trigger an analysis.
There were sevaral issues why the bot only reported on mozilla checks:
@jankeromnes Staging is back up since monday afternoon.
Great! Thanks. I have:
staging
branch to latest master
And the results are in! We even have two reviews for the price of one on https://phabricator-dev.allizom.org/D324 (I suspect that testing
is now also analyzing Phabricator-dev patches).
The following problems still need to be fixed:
readability-else-after-return
in js/src/jsapi.cpp
(found locally)clang-analyzer-security.FloatLoopCounter
in js/src/jsapi.cpp
(found locally)clang-analyzer-security.insecureAPI.UncheckedReturn
in js/src/jsapi.cpp
(found locally)misc-suspicious-semicolon
in js/src/jsapi.cpp
(found locally)modernize-redundant-void-arg
in js/src/jsapi.cpp
publish: no
)clang-analyzer-deadcode.DeadStores
in js/src/jsapi.cpp
(found locally)performance-faster-string-find
in js/src/jsapi.cpp
(found locally)performance-implicit-conversion-in-loop
in js/src/jsapi.cpp
eslint: strict
in devtools/client/menus.js
, but a local ./mach lint
finds itin_patch
)codespell: destributed
in js/ductwork/debugger/JSDebugger.cpp
codespell
doesn't find it either for some reason)When running ./mach static-analysis check
locally, I do find the missing clang-tidy
issues. However, the bot doesn't even seem to detect them (they don't appear in the logs or in the email report). Maybe another output parsing issue? It would be great to see the raw clang-tidy
output.
Additionally, the eslint: strict
defect in devtools/client/menus.js
was detected by the bot, but for some reason the bot considers it Publishable: no
(see email report):
mozlint - eslint
Path: devtools/client/menus.js
Level: error
Line: 31
Third Party: no
Disabled rule: no
Publishable: no
Is new: no
Use the global form of 'use strict'.
Update: The missing clang-tidy
defects don't seem to be a parsing issue, as revealed by dumping raw clang-tidy
outputs. I filed issue #1256 about this, and may have found a relevant difference between the in-services and out-of-services run logs.
Looks like @La0 was able to fix all undetected clang-tidy
defects by adding the right dependencies to our Nix env!
With that, the eslint: strict
remains the last issue to fix in order to fully validate analysis and enable Phabricator in production.
What's weird is that lint.py
says A mozlint issues is publishable when: file is not 3rd party rule is not disabled. In the email report, we can see that the eslint: strict
defect is neither Third party
nor Disabled rule
, yet it still shows Publishable: no
.
Aha, the analysis' report.json indicates that the eslint: strict
issue is not in_patch
, which is true because it's reported on the first code line after the commented-out "use strict"
, but that line was not modified by the patch.
Hopefully this will be fixed with BEFORE_AFTER
soon, but we don't need to block our Phabricator release on it.
The fix from #1258 was deployed to staging
, and I've sent another bad patch to D324.
Analysis is running: https://tools.taskcluster.net/groups/E3LiY0W6Q72GNJgUdrrX_w/
10/10 clang-tidy defects, 7/7 mozlint defects, 100% success! https://irccloud.mozilla.com/pastebin/goicWMJC/defects.txt
New staging analysis, just in case: https://tools.taskcluster.net/groups/Hpi4TqYKQJaGqugH6yvIgQ
EDIT: Success again!
Go for launchrelease!
Update: I've now enabled automated Phabricator reviews in production, and reviews look good!
https://phabricator.services.mozilla.com/D2066
However, both MozReview and Phabricator reviews are currently broken for patches that touch C/C++ files (because of #1263). Once that issue is fixed, we should also validate that clang-tidy
comments still look good.
Additionally, I've had to disable clang-format
globally in production (also in debug email reports), because the Phabricator reporter doesn't have a filter yet like MozReview. I've filed issue #1264 to address this.
10/10 and 7/7 on staging again! https://tools.taskcluster.net/groups/ZnCYTYy2QIqzyDnNHPiqWw/
This confirms that #1263's fix worked, and we can deploy it to production.
Additionally, we can see the analyzer raw dumps in the tasks artifacts, which is great (except clang-format.txt
, maybe because clang-format
is currently disabled on staging, although we do have a clang-format.diff
).
While waiting for general release next week, I'm trying to deploy a hot-fix for the Rust issue.
I've deployed the hot-fix to staging, and re-validated the bot: https://phabricator-dev.allizom.org/D541
Results: 4/10 expected clang-tidy
defects and 7/7 expected mozlint
defects.
EDIT: The missing clang-tidy
checks are probably due to 24e7ffa7b7e43d6adb4c67d1dc3af7b5d0241864 not being in staging/production yet. Proceeding as some comments are better than no comments.
I've deployed a hot-fix to shipit-static-analysis-production with 2 fixes from master, and:
10/10 7/7 in production! 🎉🎉🎉 https://phabricator.services.mozilla.com/D2120
(And deploying on Friday the 13th wasn't so bad... 😝)
I've tried validating MozReview the same way, but the analysis task failed with UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb5 in position 58204297: invalid start byte
:
https://tools.taskcluster.net/groups/Lp8DSs3xTHKPou13q85gUA/
I'll try to reproduce this bug locally and then bisect it.
Our automated review bot is able to analyze Phabricator code reviews.
We should evaluate its results on staging, and once satisfied we should enable it in production (and evaluate it there as well).
TODO:
clang-tidy
andeslint
issues work as well