Community
Participate
Working Groups
The "dirt report" releng test has failed the last two N-builds. I compared tonight, with last time the test did not fail, and the diff was only: $ diff dirtReport-N20150323-2000.txt dirtReport-N20150325-2000.txt 2c2 < Dirt Report for N20150323-2000 --- > Dirt Report for N20150325-2000 418a419,422 > On branch master > Your branch is up-to-date with 'origin/master'. > nothing to commit, working directory clean > Entering 'eclipse.platform.ui.tools' That is, just adding the new repository to build made the file larger, but no new dirt. I should either increase the "max size" checked, and/or look for way's to make these status messages "quiet" (so, only list "new files"). also, might want to make "last standard report" part of the data of the test, so that when we do exceed maximum, the test can do a "diff" and make it part of the error message. Also, the "maxsize" could be computed from the standard document? And/Or if the "quiet" output seems standard enough, we could always use a "diff" as part of the critera, so that even if the obtained size was smaller than max size, could (still) fail the test, and report that the standard document needs to be updated to the smaller, just obtained version.
The options --short, gives us more what we want, such as git submodule foreach git status --short produces (excerpt) ?? bundles/org.eclipse.platform.doc.isv/samples/org.eclipse.ui.examples.multipageeditor/ ?? bundles/org.eclipse.platform.doc.isv/samples/org.eclipse.ui.examples.propertysheet/ ?? bundles/org.eclipse.platform.doc.isv/samples/org.eclipse.ui.examples.readmetool/ ?? bundles/org.eclipse.platform.doc.isv/samples/org.eclipse.ui.examples.undo/ ?? bundles/org.eclipse.platform.doc.isv/workspace/ ?? bundles/org.eclipse.platform.doc.user/index/ Entering 'eclipse.platform.debug' Entering 'eclipse.platform.releng' Entering 'eclipse.platform.resources' Entering 'eclipse.platform.runtime' ?? bundles/org.eclipse.core.runtime.compatibility.registry/runtime_registry_compatibility.jar Entering 'eclipse.platform.swt' Entering 'eclipse.platform.swt.binaries' Entering 'eclipse.platform.team' Entering 'eclipse.platform.text' Entering 'eclipse.platform.ua' ?? org.eclipse.ua.tests/ua-tests.jar ?? org.eclipse.ui.intro.universal/universal.jar Entering 'eclipse.platform.ui' Entering 'rt.equinox.binaries' Entering 'rt.equinox.bundles' Entering 'rt.equinox.framework' ?? bundles/org.eclipse.equinox.launcher.cocoa.macosx.x86_64/eclipse_1608.so ?? bundles/org.eclipse.equinox.launcher.gtk.aix.ppc/eclipse_1607.so ?? bundles/org.eclipse.equinox.launcher.gtk.aix.ppc64/eclipse_1607.so ?? bundles/org.eclipse.equinox.launcher.gtk.hpux.ia64/eclipse_1607.so ?? bundles/org.eclipse.equinox.launcher.gtk.linux.ppc/eclipse_1607.so ?? bundles/org.eclipse.equinox.launcher.gtk.linux.ppc64/eclipse_1607.so We could "shorten" it further, by using --quiet, but, I then then less less useful, since hard to know which repo the "untracked" file is coming from. For example, git submodule foreach git status --short provides ?? bundles/org.eclipse.platform.doc.isv/samples/org.eclipse.ui.examples.javaeditor/ ?? bundles/org.eclipse.platform.doc.isv/samples/org.eclipse.ui.examples.multipageeditor/ ?? bundles/org.eclipse.platform.doc.isv/samples/org.eclipse.ui.examples.propertysheet/ ?? bundles/org.eclipse.platform.doc.isv/samples/org.eclipse.ui.examples.readmetool/ ?? bundles/org.eclipse.platform.doc.isv/samples/org.eclipse.ui.examples.undo/ ?? bundles/org.eclipse.platform.doc.isv/workspace/ ?? bundles/org.eclipse.platform.doc.user/index/ ?? bundles/org.eclipse.core.runtime.compatibility.registry/runtime_registry_compatibility.jar ?? org.eclipse.ua.tests/ua-tests.jar ?? org.eclipse.ui.intro.universal/universal.jar ?? bundles/org.eclipse.equinox.launcher.cocoa.macosx.x86_64/eclipse_1608.so ?? bundles/org.eclipse.equinox.launcher.gtk.aix.ppc/eclipse_1607.so ?? bundles/org.eclipse.equinox.launcher.gtk.aix.ppc64/eclipse_1607.so ?? bundles/org.eclipse.equinox.launcher.gtk.hpux.ia64/eclipse_1607.so ?? bundles/org.eclipse.equinox.launcher.gtk.linux.ppc/eclipse_1607.so ?? bundles/org.eclipse.equinox.launcher.gtk.linux.ppc64/eclipse_1607.so ?? bundles/org.eclipse.equinox.launcher.gtk.linux.ppc64le/eclipse_1605.so So, still the additon/removal of a submodule will "change the report" whether dirty or not, but I think that's ok since pretty rare.
I think best to leave report as is, since it does, also, contain branch information, and will help remind us to use a branched version of the test ... at least until we are perfectly clean? But, have, so far, modified to include a "standard report", and get the number of bytes from it, to compare with "current build results". Confirmed in workbench that test passes, when standard report was a recent N-build, (i.e. exact same size) and failed when using a recent I-build (larger report since new submodule added). Would still like to improve so that the failure contains the "diff", but that's more a nice to have enhancement, than a bug.
Opened Bug 463237 - Adjust dirt report to provide "diff" when it fails, for convenience for the "diff" enhancement. But, now test should pass, if no changes from latest N-build. And, I did fix, so it will also fail is obtained bytes are less that the standard, indicating that improvements in dirt have been made, but the message starts off with "Good news" and simply reminds to replace the standard report. I'll look forward to that failing "in the field". :)
Re-opening since still getting "false alarms", as with I20150331-0800 build. The "diff" from standard report would have been similar to that below. In other words, no new dirt, just more informative messages. So, so need to go back to "list only" mode. = = = = $ diff dirtReport-I20150331-0800.txt dirtReport-N20150329-2000.txt 2c2 < Dirt Report for I20150331-0800 --- > Dirt Report for N20150329-2000 5c5,6 < Your branch is up-to-date with 'origin/master'. --- > Your branch is ahead of 'origin/master' by 1 commit. > (use "git push" to publish your local commits) 49,52d49 < < It took 2.15 seconds to enumerate untracked files. 'status -uno' < may speed it up, but you have to be careful not to forget to add < new files yourself (see 'git help status').
Changed to use --short And updated the "standardDirtReport.txt" by running dirtReport.sh against I-build check out (build) area. http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=19b561dfb4b39d13a7a7d54f1fcfefba4952e133 http://git.eclipse.org/c/platform/eclipse.platform.releng.git/commit/?id=5deeb6ab0d6d1e225609a594d5af118fe5dd4eb4 I *think* in time for nightly ... but ... might have missed it by a minute or two.
I'll get it eventually :) For one, the releng test "failure" in N20150331-2000 was for a trivial reason. I had edited one file ... the file to create the dirt report ... to create the new standard, but upon fresh check out, it is no longer dirty: $ diff dirtReport.txt standardDirtReport.txt 2c2 < Dirt Report for N20150331-2000 --- > Dirt Report for I20150331-0800 7a8 > M production/dirtReport.sh BUT, the reason I reopened it, it that it does take another, small, conceptual change. In the parent (or, if we had other super repositories) it lists "modified submodules", such as M eclipse.jdt.core M eclipse.jdt.debug M eclipse.platform.common M eclipse.platform.runtime M rt.equinox.framework This is another part that is not really "dirt" (or, if it is, it'll be listed later, under that repository). We don't want to "fail" just because it's been a slow period, and not many modifications made (or, the reverse). So, will also add --ignore-submodules to status command.
Changed report generation script: http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/commit/?id=acf5f65554a486d9086f6c5870ea4187902c20f3 And, standard file: (this time remembering just to delete the local change to dirtReport.sh http://git.eclipse.org/c/platform/eclipse.platform.releng.git/commit/?id=a81a9d20b39ed1d8950c46683a267b1cedb9f1d6
