[rfc] jtreg's jenkins out of sync?
Mani Sarkar
sadhak001 at gmail.com
Mon Apr 20 22:28:05 UTC 2015
@Jiri, here's the link to 156, contributed by you -
http://hg.openjdk.java.net/code-tools/jtreg/rev/7906b5ebfc75
and I cleared the workspace again and rebuilt jreg, here's the head of the
logs:
Building remotely on 78eb14ac
<https://adopt-openjdk.ci.cloudbees.com/computer/78eb14ac>
(lxc-fedora17 m1.small small) in workspace
/scratch/jenkins/workspace/jtreg
$ 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 7906b5ebfc75d9b39033acfcc56c627898a782a4
changeset: 156:7906b5ebfc75
tag: tip
user: jjg
date: Thu Apr 16 17:45:57 2015 -0700
summary: Add support for jdk.version.major for use in @requires
[jtreg] $ hg log --template "<changeset node='{node}'
author='{author|xmlescape}' rev='{rev}'
date='{date}'><msg>{desc|xmlescape}</msg><added>{file_adds|stringify|xmlescape}</added><deleted>{file_dels|stringify|xmlescape}</deleted><files>{files|stringify|xmlescape}</files><parents>{parents}</parents></changeset>\n"
--rev default:0 --follow --prune
7906b5ebfc75d9b39033acfcc56c627898a782a4 --encoding UTF-8
--encodingmode replace
[jtreg] $ /bin/bash /tmp/hudson578058129869953677.sh
Tag: jtreg4.1-b11
VersionNumber: 4.1
BuildNumber: b11
destination directory: jtreg
adding changesets
adding manifests
adding file changes
added 146 changesets with 1518 changes to 650 files
updating to branch default
623 files updated, 0 files merged, 0 files removed, 0 files unresolved
changeset: 145:04f40c388713
tag: tip
user: jjg
date: Thu Mar 12 12:55:02 2015 -0700
summary: include resource file in image
tip 145:04f40c388713
jtreg4.1-b10 114:8c3179c3ebda
jtreg4.1-b09 84:c54815dea64c
jtreg4.1-b08 80:e08a5e0b79ba
jtreg4.1-b07 53:8ab579624a50
jtreg4.1-b06 33:d47a6e238c3e
jtreg4.1-b05 8:46b8c02be3b3
jtreg4.1-b04 6:cbc1f04a52ea
jtreg4.1-b03 4:bd7a3ed1210f
jtreg4.1-b02 2:2cf779985e18
jtreg4.1-b01 0:9f51ef22f00a
Also remembered that we only build from the tip and the tip shows
145:04f40c388713
(http://hg.openjdk.java.net/code-tools/jtreg/rev/04f40c388713).
Cheers,
Mani
On Mon, Apr 20, 2015 at 11:21 PM, Mani Sarkar <sadhak001 at gmail.com> wrote:
> All I did to refresh the build was clearing the workspace - and it is the
> best I can control from our end.
>
> @Jiri - have you tried fetching the source and building it locally?
>
> @Jonathan - any ideas what Jiri is experience, something you know about?
>
> On Mon, Apr 20, 2015 at 12:26 PM, Jiri Vanek <jvanek at redhat.com> wrote:
>
>> On 04/20/2015 12:59 PM, Martijn Verburg wrote:
>>
>>> Hmm,
>>>
>>> I think Mani did see that change set in there, Mani?
>>>
>>
>> I thought so. It is correctly in hg log of build.
>>
>> But Nope. Non of the build s sine /265/ do not have it.
>> Most surprising is, that also workspace (accessible via webgui) is
>> missing this changeset.
>>
>>
>> J.
>>
>>>
>>> Cheers,
>>> Martijn
>>>
>>> On 20 April 2015 at 11:13, Jiri Vanek <jvanek at redhat.com <mailto:
>>> jvanek at redhat.com>> wrote:
>>>
>>> On 04/20/2015 10:45 AM, Martijn Verburg wrote:
>>>
>>> Mercurial sometimes gets out of synch/date. It usually resolves
>>> itself on the next change set.
>>>
>>>
>>> Sorry again.
>>>
>>>
>>> I have checked the built jars and worksapces. The last chngeset is
>>> still missing...
>>>
>>> I feel little bit bad about that. But that hg out of sync is quite
>>> strong...
>>>
>>> J.
>>>
>>> Cheers,
>>> Martijn
>>>
>>> On 20 April 2015 at 09:27, Jiri Vanek <jvanek at redhat.com
>>> <mailto:jvanek at redhat.com> <mailto:jvanek at redhat.com <mailto:
>>> jvanek at redhat.com>>> wrote:
>>>
>>> On 04/19/2015 08:07 PM, Martijn Verburg wrote:
>>>
>>> Hi all,
>>>
>>> For those wondering, this resolved itself.
>>>
>>>
>>> ok. I did:)
>>>
>>> How did it resolved itself?
>>>
>>>
>>> Cheers,
>>> Martijn
>>>
>>>
>>>
>>> The build Mani started already had my deeply wonted change.
>>>
>>> But I think the question is still in place - Why build,
>>> initiated by change 156 in repo was based on changeset 155...
>>>
>>> I do not mean ti somehow wrongly, But seems wrong to me.
>>>
>>>
>>> Thanx!
>>>
>>> J.
>>>
>>>
>>> On 17 April 2015 at 18:09, Jiri Vanek <
>>> jvanek at redhat.com <mailto:jvanek at redhat.com> <mailto:jvanek at redhat.com
>>> <mailto:jvanek at redhat.com>> <mailto:jvanek at redhat.com <mailto:
>>> jvanek at redhat.com> <mailto:jvanek at redhat.com <mailto:jvanek at redhat.com>>>>
>>> wrote:
>>>
>>>
>>> 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.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
> --
> @theNeomatrix369 <http://twitter.com/theNeomatrix369>* | **Blog
> <http://neomatrix369.wordpress.com>** | *LJC Associate & LJC Advocate
> (@adoptopenjdk & @adoptajsr programs)
> *Meet-a-Project - *MutabilityDetector
> <https://github.com/MutabilityDetector>* | **Bitbucket
> <https://bitbucket.org/neomatrix369>* * | **Github
> <https://github.com/neomatrix369>* * | **LinkedIn
> <http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
> *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
>
> *Don't chase success, rather aim for "Excellence", and success will come
> chasing after you!*
>
--
@theNeomatrix369 <http://twitter.com/theNeomatrix369>* | **Blog
<http://neomatrix369.wordpress.com>** | *LJC Associate & LJC Advocate
(@adoptopenjdk & @adoptajsr programs)
*Meet-a-Project - *MutabilityDetector
<https://github.com/MutabilityDetector>* | **Bitbucket
<https://bitbucket.org/neomatrix369>* * | **Github
<https://github.com/neomatrix369>* * | **LinkedIn
<http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
*Come to Devoxx UK 2015:* http://www.devoxx.co.uk/
*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*
More information about the adoption-discuss
mailing list