Project

General

Profile

Bug #689

nightly.sh doesn't do fresh bringovers

Added by Dan McDonald almost 10 years ago. Updated almost 10 years ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
tools - gate/build tools
Start date:
2011-02-03
Due date:
% Done:

100%

Estimated time:
Difficulty:
Tags:
Gerrit CR:

Description

When I run nightly, I often do it where there's no pre-existing build workspace: I expect nightly to do a pull/bringover immediately.

I cannot do this now, because I get:

nightly: Error: <$CODEMGR_WS> is not a directory.

nightly should do a fresh bringover from $CLONE_WS if $CODEMGR_WS doesn't exist yet.

#1

Updated by Rich Lowe almost 10 years ago

Yeah, the checks at source:usr/src/tools/scripts/nightly.sh@13280#L1288 are both bogus.
If they're to be made, they need to be made way down around line 2506 after any bringover has happened.

#2

Updated by Roland Mainz almost 10 years ago

  • Category changed from manpage - manual pages to tools - gate/build tools

Erm... the checks were added to prevent nightly.sh from running "amok" (e.g. it tries hard to continue and sometimes writing over stuff which is not even remotely related to a gate) if it encounters a directory which is not a workspace. This has been a source of serious trouble for beginners in the past and that's why I added the safety checks.

Question (just to verify that my proposed patch is completely correct):

nightly should do a fresh bringover from $CLONE_WS if $CODEMGR_WS doesn't exist yet.

That means the variable CODEMGR_WS exists but points to a location which does not exist yet, right ? If "yes" ... can I assume this functionality is not used if NIGHTLY_OPTIONS contains "n", right ?

#3

Updated by Rich Lowe almost 10 years ago

Roland Mainz wrote:

Erm... the checks were added to prevent nightly.sh from running "amok" (e.g. it tries hard to continue and sometimes writing over stuff which is not even remotely related to a gate) if it encounters a directory which is not a workspace. This has been a source of serious trouble for beginners in the past and that's why I added the safety checks.
Question (just to verify that my proposed patch is completely correct):

nightly should do a fresh bringover from $CLONE_WS if $CODEMGR_WS doesn't exist yet.

That's actually wrong, it should bringover from BRINGOVER_WS (which defaults to CLONE_WS). The reason why is lost on me, but as you found out here, changing stuff, no matter how sensible, tends to break an outlier.

That means the variable CODEMGR_WS exists but points to a location which does not exist yet, right ? If "yes" ... can I assume this functionality is not used if NIGHTLY_OPTIONS contains "n", right ?

Yes. to both That's why I suggested moving your checks to after the bringover has happened. If none is being done, one failed, or whatever, aborting there is great. Just not scuppering the nightly-creates-workspace model.

#4

Updated by Roland Mainz almost 10 years ago

Rich Lowe wrote:

Roland Mainz wrote:

Erm... the checks were added to prevent nightly.sh from running "amok" (e.g. it tries hard to continue and sometimes writing over stuff which is not even remotely related to a gate) if it encounters a directory which is not a workspace. This has been a source of serious trouble for beginners in the past and that's why I added the safety checks.
Question (just to verify that my proposed patch is completely correct):

nightly should do a fresh bringover from $CLONE_WS if $CODEMGR_WS doesn't exist yet.

That's actually wrong, it should bringover from BRINGOVER_WS (which defaults to CLONE_WS). The reason why is lost on me, but as you found out here, changing stuff, no matter how sensible, tends to break an outlier.

Grumpf... please file a seperate bug for investigation...

That means the variable CODEMGR_WS exists but points to a location which does not exist yet, right ? If "yes" ... can I assume this functionality is not used if NIGHTLY_OPTIONS contains "n", right ?

Yes. to both That's why I suggested moving your checks to after the bringover has happened. If none is being done, one failed, or whatever, aborting there is great. Just not scuppering the nightly-creates-workspace model.

Ok... here is my plan:
1. I copy (not move) the checks to line 2506 after any bringover has happened. This should catch any failed bringover or other weired issues before damage happens
2. The first set of checks get wrapped in a $ if [[ "$NIGHTLY_OPTIONS" == n ]] ; then ... fi # because "n" is enabled by default in the illumos.sh we ship in onbld. This should preserve the original safeguard for beginners and fix the problem Dan has...

... does that sound Ok ?

#5

Updated by Roland Mainz almost 10 years ago

(please add [[ ]] (square brackets) into my last comment... somehow this bugtracker thought it can remove it. Damn xx@@!!!!-thing... ;-( )
#6

Updated by Rich Lowe almost 10 years ago

Roland Mainz wrote:

Rich Lowe wrote:

Roland Mainz wrote:
That's actually wrong, it should bringover from BRINGOVER_WS (which defaults to CLONE_WS). The reason why is lost on me, but as you found out here, changing stuff, no matter how sensible, tends to break an outlier.

No, what I describe is what nightly already does. I was clarifying in case you thought it was something else which needed to be changed :)

Ok... here is my plan:
1. I copy (not move) the checks to line 2506 after any bringover has happened. This should catch any failed bringover or other weired issues before damage happens
2. The first set of checks get wrapped in a $ if [[ "$NIGHTLY_OPTIONS" == n ]] ; then ... fi # because "n" is enabled by default in the illumos.sh we ship in onbld. This should preserve the original safeguard for beginners and fix the problem Dan has...

... does that sound Ok ?

I think that this sounds good, yes.

#7

Updated by Dan McDonald almost 10 years ago

Rich Lowe wrote:

Roland Mainz wrote:

2. The first set of checks get wrapped in a $ if [[ "$NIGHTLY_OPTIONS" == n ]] ; then ... fi # because "n" is enabled by default in the illumos.sh we ship in onbld. This should preserve the original safeguard for beginners and fix the problem Dan has...

... does that sound Ok ?

I think that this sounds good, yes.

I think this is okay as well.

#8

Updated by Gordon Ross almost 10 years ago

Eventually, I'd prefer that nightly not "know" about how to "bringover", and not try.
Perhaps this is a radical idea, but we have way too much mutual entanglement in
our world, and this is just one of many examples. Better to have a tool that does
one job: run my build.

#9

Updated by Roland Mainz almost 10 years ago

  • % Done changed from 0 to 30

Test builds in progress. ETA for webrev: ~~4-6 hours+dinner.

#10

Updated by Garrett D'Amore almost 10 years ago

  • Status changed from New to Resolved
  • % Done changed from 30 to 100

Fixed in:

changeset: 13290:6489e7702a16
tag: tip
user: Roland Mainz <>
date: Thu Feb 17 15:06:39 2011 -0800
description:
689 nightly.sh doesn't do fresh bringovers
Reviewed by: Dan McDonald <>
Reviewed by: Olga Kryzhanoska <>
Approved by: Garrett D'Amore <>

Also available in: Atom PDF