Fwd: Re: [rfc] jtreg's jenkins out of sync?

Jiri Vanek jvanek at redhat.com
Fri Apr 17 17:09:15 UTC 2015 

Hi!

Maybe I'm wrong, but it seems to me that jenkins is not pulling latest changesets as expected:

Look to the:
https://adopt-openjdk.ci.cloudbees.com/job/jtreg/265/
It is now latest build. It clearly says that it was started by scm change, last change is the jdk.version.major bla bla bal...

But - download the jar and you will find my changeset missing.
Looking to the output: https://adopt-openjdk.ci.cloudbees.com/job/jtreg/265/consoleText

It clearly says:
$ hg clone --rev default --noupdate http://hg.openjdk.java.net/code-tools/jtreg /scratch/jenkins/workspace/jtreg
adding changesets
adding manifests
adding file changes
added 157 changesets with 1542 changes to 650 files
[jtreg] $ hg update --rev default
623 files updated, 0 files merged, 0 files removed, 0 files unresolved
[jtreg] $ hg log --rev . --template {node}
[jtreg] $ hg log --rev . --template {rev}
[jtreg] $ hg log --rev e88738b571dee0fb28e40ef14260b78fa267e4f3
changeset:   155:e88738b571de
user:        jjg
date:        Mon Mar 30 17:56:11 2015 -0700
summary:     Improved asmtools handling


Which is the my_comit-1. And is Also a bit surprising. Because my Changeset had id 156. The clone cloned 157 chnagesets but as tip was used 155.

So maybe there is -2 instead -1 somewhere :))

Nope, joking... If you may fix/reschedule whatever I will be glad. I do not wont to upload on my machines my self built version.


TY and sorry if I'm wrong...

J.


>
> -- Jon
>
> On 04/16/2015 12:16 AM, Jiri Vanek wrote:
>> On 04/15/2015 06:51 PM, Jonathan Gibbons wrote:
>>> Jiri,
>>>
>>> Thanks.
>>>
>>> On the build.xml, I note that "make" is the preferred way to build and test jtreg; the Ant file is
>>
>> Yes. I understand it.
>>> provided as a convenience for use while working in an IDE like NetBeans. It was not practical to
>> And it is very cool :)
>>
>>> port all the tests from the "make" world into the Ant world, and so "make" remains the definitive
>>
>> Sure.
>>> build tool.  Looking at your build change, while jh.jar is required, it is normally pulled in
>>> because of a Class-Path reference in javatest.jar, but perhaps you don't have that reference in your
>>> build of javatest.jar.
>>
>> Thats weird. It have:
>>
>>  unzip -p /opt/jtharness/4.3/lib/javatest.jar META-INF/MANIFEST.MF | grep Class-Path
>> Class-Path: jh.jar
>>
>> Is the change acceptable (no meter of build.xml hunk)? If so, when it can be expected to be seen in jenkins build?
>>
>> J
>>
>>>
>>> -- Jon
>>>
>>> On 04/15/2015 08:40 AM, Jiri Vanek wrote:
>>>> Hi Jonatan.
>>>>
>>>>
>>>> So here you have pacth with this functionality. Tested on jdk 7 and 8 and works fine.
>>>>
>>>> The change was really minimalistical - your engine eems to be prepared for it! Grate:)
>>>>
>>>> You may note one change in build.xml - feel free to discard it, but I was not able to build
>>>> without it.
>>>>
>>>>
>>>> Thanx!
>>>>
>>>>  J.
>>>>
>>>> On 04/11/2015 03:26 AM, Jonathan Gibbons wrote:
>>>>> Jiri,
>>>>>
>>>>> How about a variant of 0, which is to define a new property, perhaps called "jdk.version.major" or
>>>>> something like that, which is defined to be a simple integer, for easy use with the existing
>>>>> comparison mechanism.  That leaves open the use for jdk.version to be a more detailed string, with
>>>>> potentially the possibility of doing version comparisons later on, if that should prove necessary.
>>>>>
>>>>> -- Jon
>>>>>
>>>>>
>>>>> On 04/10/2015 03:11 AM, Jiri Vanek wrote:
>>>>>> On 04/09/2015 05:30 PM, Jonathan Gibbons wrote:
>>>>>>> The current behavior of the jdk.version has been to return 1.major for existing releases, with
>>>>>>> the
>>>>>>> proposal to go to something beginning with 9 for JDK 9 onwards.
>>>>>>>
>>>>>>
>>>>>> 0. Yes. Thats definitely the right thing to do.
>>>>>>
>>>>>> So why not to "just keep backward compatibility for jdk5-8" ? If returned version would match
>>>>>> 1.{5,6,7,8}.X consider it as 5,6,7 or 8?
>>>>>>
>>>>>> The touch in code will be minimalist, we will be in safe integers,
>>>>>>
>>>>>>> I don't think it is right to renumber releases in hindsight. jdk.version should stay "reasonably
>>>>>>> close" to the beginning of the string obtained from "java -version".
>>>>>>>
>>>>>>> So that means we have the following possibilities:
>>>>>>> 1. only allow one dot, and treat these numbers as floating point. That's pretty hacky.
>>>>>>
>>>>>> I like this:) But yes.. it is hacky :(  And you will still need handle other possible dots after
>>>>>> first (eg removal of all no digit chars?)
>>>>>>
>>>>>> Although it may be pretty powerfull at the end, it may be confusing even misleading
>>>>>> (eg 1.7.a5 will suddenly be lower hiogher then 1.7.b4 and many similar and much less visible)
>>>>>>
>>>>>>> 2. introduce "version types" into the @requires expression engine, and make the relation operators
>>>>>>> polymorphic
>>>>>>
>>>>>>
>>>>>> Well this may be pretty cool, and will solve the issue with jtregs testing features like nimbus
>>>>>> (mentioned somewhere in this thread..)
>>>>>>
>>>>>>
>>>>>> So long story short.  I vote for *0* for it simplicity. But if you think 2 is worthy of effort
>>>>>> then why not . But design will need much more thinking then I originally hoped to sacrifice. But I
>>>>>> think it is not worthy.
>>>>>>
>>>>>>
>>>>>> Also I guess I can not have final word as you are an guru here. So whatever you suppose is good, I
>>>>>> can start to work on it.
>>>>>>
>>>>>> Thanx!
>>>>>>
>>>>>>   J.
>>>>>>>
>>>>>>> -- Jon
>>>>>>>
>>>>>>> On 04/09/2015 12:53 AM, Jiri Vanek wrote:
>>>>>>>> ping?
>>>>>>>>
>>>>>>>> If the most simple way is the way to go, then - as your initial impl is based on jdk9, so it
>>>>>>>> expect one number on each side, then simple extending for backward ocmpatibility to change
>>>>>>>> 1.{8,7,6,5}.whatever to simple number should be right thing to do an easy way to go.
>>>>>>>>
>>>>>>>> Any more granular thoughts may come in later.
>>>>>>>>
>>>>>>>> Can I proceed with this patch?
>>>>>>>>
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>>   J.
>>>>>>>>
>>>>>>>> On 04/02/2015 01:12 PM, Jiri Vanek wrote:
>>>>>>>>> One more hint.
>>>>>>>>>
>>>>>>>>> When I originally read
>>>>>>>>>
>>>>>>>>>  > 4. @requires. This is a relatively new feature. You can put a declarative tag in a test
>>>>>>>>> description
>>>>>>>>>  > of the form "@requires expr" where there is a variety of terminals, of which jdk.version
>>>>>>>>> is but
>>>>>>>>>  > one.   So you could add a line like
>>>>>>>>>  >      @requires  jdk.version <=1.6 || jdk.version >1.7 || jdk.version = "1.4.2"
>>>>>>>>>  > Not as compact as your proposal, but it exists today.
>>>>>>>>>
>>>>>>>>> It seemed to me that full version sort is included.
>>>>>>>>>
>>>>>>>>> so eg  1.4.2 < 1.8 < 9 < 9.2
>>>>>>>>> but also 1.7.0_20 < 1.7.0_40
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Also my original impression from jep was, that backward compatibility returnnig 1.9.0_X will be
>>>>>>>>> preserved.
>>>>>>>>>
>>>>>>>>> Currently I do not need this, but my colleague mentioned cases where it can be useful.
>>>>>>>>> Eg nimbus  was introduced in uSomething. So any tests to nimbus would have @requires >=
>>>>>>>>> 1.7.0_Something (instead of programmed failback "if no nimbus then exit 0" :)
>>>>>>>>>
>>>>>>>>> Maybe it is really not needed, but when such an nice feature started to exists, it would be
>>>>>>>>> nice to
>>>>>>>>> have it as capable as possible.
>>>>>>>>>
>>>>>>>>> J.
>>>>>>>>>
>>>>>>>>> On 04/02/2015 11:19 AM, Jiri Vanek wrote:
>>>>>>>>>> On 04/01/2015 08:32 PM, Jonathan Gibbons wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 04/01/2015 10:34 AM, Jiri Vanek wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>   * @requires jdk.version <= 7
>>>>>>>>>>>>> leads to
>>>>>>>>>>>>> test result: Error. Error evaluating expression: invalid numeric value: 1.8
>>>>>>>>>>>>>
>>>>>>>>>>>>> Is it expected bahviour? I tried also with various spaces/nospace....
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>> ping? Is it expected? If not, I will provide you a fix.
>>>>>>>>>>>>
>>>>>>>>>>>> J.
>>>>>>>>>>>
>>>>>>>>>>> With hindsight, I can see that this is to be expected, which is not to say that it is good.
>>>>>>>>>>>
>>>>>>>>>>> Going forward, I'm not sure what the correct fix will be, especially given the upcoming JEP
>>>>>>>>>>> for
>>>>>>>>>>> semantic versioning.
>>>>>>>>>>> http://openjdk.java.net/jeps/223
>>>>>>>>>>
>>>>>>>>>> Yes, I'm aware of this jep.
>>>>>>>>>>>
>>>>>>>>>>> Before you provide a fix, I'd be interested to hear suggestions on what the fix should be.
>>>>>>>>>>> One
>>>>>>>>>>> solution is that we should just allow numbers to be represented as Double as well as Long. A
>>>>>>>>>>> different solution would be to introduce a "version" type somehow.
>>>>>>>>>>
>>>>>>>>>> When I saw the behavior, And realized that jep 233 was target, I was thinking  that
>>>>>>>>>>  >>>   * @requires jdk.version <= 7
>>>>>>>>>>  >>> leads to
>>>>>>>>>>  >>> test result: Error. Error evaluating expression: invalid numeric value: 1.8
>>>>>>>>>>
>>>>>>>>>> Is correct way to do. And so, if this Error is hit, try to remove leading 1. and strip all
>>>>>>>>>> behind
>>>>>>>>>> next dot including that dot.
>>>>>>>>>>
>>>>>>>>>> For jdk9+ single number is expected.
>>>>>>>>>>
>>>>>>>>>> Otherwise the qeustion is a bit different. What is expected from "jdk.version" Only mayor
>>>>>>>>>> number
>>>>>>>>>> like 1.4.2, 1.7.0, 1.8.0, 9, 10, or more detailed version?
>>>>>>>>>>
>>>>>>>>>> I would vote for that simple approach, but probably only because it suits my needs now.
>>>>>>>>>> Cases like 1.4.2 in past 1.4.0 may be expected... But still, non of those should causes
>>>>>>>>>> compilation
>>>>>>>>>> incompatibility.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thank you very much for cooperation!
>>>>>>>>>>   J.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

More information about the adoption-discuss mailing list