Opened 10 years ago

Closed 10 years ago

Last modified 13 months ago

#4862 closed defect (fixed)

BUILDBOT: configure phase not handled well

Reported by: fingolfin Owned by: dhewg
Priority: normal Component: --Other--
Keywords: Cc:


Looking at our buildbot, every build has at least two phases: A "configure" and a "build" phase. However, the "configure" phase apparently does nothing right now, even though IMO it should: I would expect that if the "configure" script is modified, then our buildbot would re-run it, with the currently active set of parameters, during the configure phase.

What happens instead is that nothing is done in the configure phase (always), and our build system takes care of re-running configure; see <>.

This is bad for at least two reasons:
1) It's confusing that if one is looking for configure re-runs, then this information is *not* on the "configure phase" page
2) If we want to make changes to the configure params passed by buildbot to configure, there is currently no good way to get buildbot to do that.

We should look into fixing this up

Ticket imported from: #2989300. Ticket imported from: bugs/4862.

Change History (5)

comment:1 by dhewg, 10 years ago

I disliked 1) from day one, but unfortunately I didn't find a non-hackish way to do it... yet.

The problem is buildbot's slave and master architecture. While the RemoteCommand class is pure python code, it's executed on the master. Afaict there is no member you can overwrite to make python code run on the slave, like a simple "if os.stat('').st_mtime < os.stat('configure').st_mtime" we could use here ;)


Our setup has only one master and one slave, and both on the same box. With that info, a quick and dirty way might be to check the slave build folder within the Configure class. But that's a nasty approach, because we don't even know the slave path, we would have to hardcode it. (The slave is completely independent of the master. It's a distinct setup, which could be anywhere within the filesystem).

It might be possible to split the Configure build step into two commands. The first just checks if is too old and stores that as a build property, and the second command uses that info in the start() method to return SKIPPED if a configure run is not necessary. But then again, it's not clear to me how to realise the first part too :\

The current approach is a result of "I tried, but didn't know any better". Suggestions welcome :)

comment:2 by dhewg, 10 years ago

tried to solve 1) with r48960 with the mentioned splitted-step/build-property approach.
Let's wait and see...

comment:3 by dhewg, 10 years ago

Owner: set to dhewg

comment:4 by dhewg, 10 years ago

Resolution: fixed
Status: newclosed

comment:5 by digitall, 13 months ago

Component: --Other--
Note: See TracTickets for help on using tickets.