Once we get to a point where we can get a boolean "good/bad" out of the static analysis, we should set it up to run on mozilla-inbound pushes (and on try). Prerequisites: 1. Eliminate all false positives or use annotations to detect which ones we don't care about 2. Generate GCC, sixgill, etc. packages installable on a buildbot slave 3. Add those packages added to the releng yum repos that slaves pull from 4. Write the script (similar to spidermonkey.sh) that runs the analysis and reports the outcome 5. Define new spidermonkey project jobs in buildbot-configs/mozilla/config.py to define the new Builders (include the packages from step 2 in the mock_packages portion) ...or something like that.
Steve says the next steps for TBPL integration are: 1. getting a usable gcc built & packaged & installed on the linux64 build machines 2. writing a mozharness script for running the analysis 3. modifying the buildbotcustom code to be able to use mozharness jobs for spidermonkey project builds 4. extracting out the useful output from the analysis (perhaps boiling it down to a pass/fail, or number of hazards?) and feeding it through the buildbot system 4b. bug 749421 seems to be about a mechanism for uploading data from test jobs, which is related to what we'd like here. We might be able to use the same mechanism when it lands. (Note that this would be a build job, not a test job, though.) 5. defining & activating the new builders and arguing about whether to show their results by default on tbpl or not. (They can stay hidden for a while.)
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.