RFR: 8192837 Need new test for release file info

Randy Crihfield Randy.Crihfield at Oracle.com
Tue Dec 19 13:11:43 UTC 2017


Understood, thanks.  Because of a JPRT bug I'm reluctant to insist the 
"line" part is always there, I was told it could cause false failures in 
many cases.  There actually is a positive case in the works but the SQE 
in me likes to keep the cases separate so one might know what actually 
failed without deep diving every time, makes triage faster.

Thanks for your detailed help!

Randy

On 12/18/17 08:10 PM, Martin Buchholz wrote:
> Thanks for implementing my test suggestions, Randy.  Looks good.
>
> It looks like all builds should have a "release" file, and all 
> "release" files should have a SOURCE= line, so I might make those 
> checks unconditonally.  If there are other sanity checks for the 
> "release" file, then I might try to coalesce the tests so there is 
> less duplication.
>
> On Mon, Dec 18, 2017 at 4:49 PM, Randy Crihfield 
> <Randy.Crihfield at oracle.com <mailto:Randy.Crihfield at oracle.com>> wrote:
>
>
>     If I understand this correctly, this fixes the bug and gives more
>     clarity.
>
>     http://cr.openjdk.java.net/~shurailine/8192837/webrev.02/
>     <http://cr.openjdk.java.net/%7Eshurailine/8192837/webrev.02/>
>
>     Randy
>
>
>     On 12/18/17 07:23 PM, Martin Buchholz wrote:
>>        28  * @summary Test to verify release file not contains close repo info if it's open bundle
>>     "closed" would be much clearer than "close"
>>
>>     ---
>>
>>        58                 readIn.trim();
>>     This is a classic bug that should really be caught by static
>>     analysis somewhere (e.g.
>>     http://errorprone.info/bugpattern/CheckReturnValue
>>     <http://errorprone.info/bugpattern/CheckReturnValue>)
>>
>>
>>     On Mon, Dec 18, 2017 at 4:05 PM, Randy Crihfield
>>     <Randy.Crihfield at oracle.com <mailto:Randy.Crihfield at oracle.com>>
>>     wrote:
>>
>>         On 12/18/17 02:40 PM, Martin Buchholz wrote:
>>
>>         Here it is Mr Martin
>>
>>         http://cr.openjdk.java.net/~shurailine/8192837/webrev.01/
>>         <http://cr.openjdk.java.net/%7Eshurailine/8192837/webrev.01/>
>>
>>         Fixed the bugID link and changed the variables to what I
>>         believe you are asking for.
>>         Also made the bug public.
>>         Thanks for the help!
>>
>>         Randy
>>
>>
>>>         Hi Randy,
>>>
>>>         Your bugid link in the webrev is broken - points to bogus
>>>         https://bugs.openjdk.java.net/browse/https://bugs.openjdk.java.net/browse/JDK-8192837
>>>         <https://bugs.openjdk.java.net/browse/https://bugs.openjdk.java.net/browse/JDK-8192837>
>>>
>>>         Please fix.
>>>
>>>         OTOH, https://bugs.openjdk.java.net/browse/JDK-8192837
>>>         <https://bugs.openjdk.java.net/browse/JDK-8192837> is not
>>>         public - please fix.
>>>
>>>            92         String sJdkPath = System.getProperty("test.jdk");
>>>            93         String sRuntime = System.getProperty("java.runtime.name  <http://java.runtime.name>");
>>>         This looks like Hungarian Notation, which is not normal in
>>>         openjdk code, so s/sJdkPath/jdkPath/ etc.
>>>
>>>
>>>         On Mon, Dec 18, 2017 at 8:55 AM, Randy Crihfield
>>>         <Randy.Crihfield at oracle.com
>>>         <mailto:Randy.Crihfield at oracle.com>> wrote:
>>>
>>>             I have created an OpenJDK negative test that confirms
>>>             the closed source files are not included in the SOURCE.
>>>
>>>             Version of the actual test for review:
>>>
>>>             http://cr.openjdk.java.net/~shurailine/8192837/webrev.00/ <http://cr.openjdk.java.net/%7Eshurailine/8192837/webrev.00/>
>>>
>>>             Any comments/suggestions are welcome, also I will need a
>>>             sponsor for it at the end…
>>>
>>>             Randy
>>>
>>>
>>
>>
>
>



More information about the build-infra-dev mailing list