Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 366233 - fix recent build breaks
Summary: fix recent build breaks
Status: RESOLVED FIXED
Alias: None
Product: Orbit
Classification: Tools
Component: releng (show other bugs)
Version: unspecified   Edit
Hardware: PC Linux
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: David Williams CLA
QA Contact: Project Inbox CLA
URL:
Whiteboard:
Keywords:
Depends on: 361131
Blocks:
  Show dependency tree
 
Reported: 2011-12-09 13:21 EST by David Williams CLA
Modified: 2011-12-09 15:13 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Williams CLA 2011-12-09 13:21:48 EST
While investigating some mysterious build breaks today, I'm noticing (and fixing) a number of odd or less than idea things. And, getting to be so many :( thought I'd better document them at least a little. 

First, build was failing to "fetch" the eclipse SDK but the diagnostics there are not good, so error messages don't help, so improving the ant file

org.eclipse.orbit.releng.builder/scripts/dependency/build.xml

Ultimately, it appears, the "dependencies.properties" file is not being fetched, so some bad data is being passed to the dependency/build.xml file, so fixed that to fail faster, and provide better diagnostic info. 

And, while doing that, still wanted to "publish log" etc early, and while doing that, found a few instances in build and in releng.control, where we were incorrectly using $cctimestamp instead of $timestamp (timestamp is based on cctimestamp, since we are using cc to do the builds, bug a) want that fact to be localized to one place for if/when we change and b) guess these cases of "cctimestamp" normally work, if everything runs in the main-path order, but it is not set in error cases, so we were trying to create directories with the name, literally, of ${cctimestamp} (it is amazing what linux lets you do :)
Comment 1 David Williams CLA 2011-12-09 13:36:16 EST
While investigating why map file directory is not being fetched and copied where expected, I did notice an odd bit of script where we appear to "tag" the map files twice. I assume a long standing copy/paste error that "doesn't hurt anything"? ... but will change that to do it just once. 

This was in in middle of (around line 56) of 
org.eclipse.orbit.releng.builder/scripts/build/maptasks.xml


        <antcall
            target="tagMapFiles">
            <param
                name="cvsPackage"
                value="${mapcomponent}"/>
        </antcall>
        <antcall
            target="tagMapFiles">
            <param
                name="cvsPackage"
                value="${mapcomponent}"/>
        </antcall>
Comment 2 David Williams CLA 2011-12-09 14:00:00 EST
Status: I've discovered the check out of maps is failing with a message similar to 

385 [orbit-set1]       [cvs] cvs [checkout aborted]: unexpected '\x65' reading revision number in RCS file /cvsroot/tools/org.eclips    e.orbit/org.eclipse.orbit.releng/.project,v

I think I've seen this before, and will investigate or open a bug for webmasters. 

But, I think there's two implications for improving build scripts. 

1. We should likely run with cvs_quiet = false for most things (it was not in log file, initially, until I tweaked some settings on my local machine). 

2. Once we do that (let cvs be noisy), we could (should?) call "checkForFastFail" after trying to get maps, builders, etc., since one thing that check looks for "checkout aborted" ... hence, resulting in better detection and diagnosis of reason for build failure.
Comment 3 David Williams CLA 2011-12-09 14:47:15 EST
The root problem has happened before. I have re-opened bug 361131. 

But ... all the improvements done here really help to get better diagnostic messages for future!
Comment 4 David Williams CLA 2011-12-09 15:13:53 EST
root problem fixed. Build progressing. Improvements in build scripts here are gravy. :)