Smalltalk › Squeak › Squeak - Dev

CI works! (was Re: [squeak-dev] Logging progress during an update)

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Frank Shearar-3

CI works! (was Re: [squeak-dev] Logging progress during an update)

On 17 September 2013 08:40, Frank Shearar <[hidden email]> wrote:
> I really do need to take the time to look at that guy... So I should, for the moment, just need to catch the PIEs to log? I tried that but maybe I did it wrong. I'll take another run at it. We definitely do need a command line processor in trunk, at any rate. Loads of the CI work is working around our lack thereof.

Well, I haven't managed to log updates, but I _have_ finally managed
to fix the CI update scripts. A merge conflict caused an
MCMergeBrowser to pop up and halt the world. CI assumed the task had
hung (which it had, effectively), and hilarity ensued.

http://build.squeak.org/job/SqueakTrunk/532/console shows a properly
working update. (I have no idea where all those empty lines are coming
from... unless they're progress indications?? Could be!)

The script didn't just bail because an MCMergeResolutionRequest has a
#defaultAction (to bring up the dialog). Since the script doesn't
catch that exception, the #defaultAction triggers, popping up the
dialog.

Without having thought it through, one possible solution is to _never_
create dialogs directly, but always through ToolSet. (So Monticello
would extend ToolSet's API, for instance.) That way, a
CommandLineToolSet could bail with a decent error message, while (in
this case) the StandardToolSet could pop up a MCMergeBrowser.

frank

Frank Shearar-3

Re: CI works! (was Re: [squeak-dev] Logging progress during an update)

On 20 September 2013 12:29, Frank Shearar <[hidden email]> wrote:
> On 17 September 2013 08:40, Frank Shearar <[hidden email]> wrote:

> (I have no idea where all those empty lines are coming
> from... unless they're progress indications?? Could be!)

They are! ProgressInitiationExceptions don't have useful messageTexts
though, so I hacked in logging "e instVarNamed: 'progressTitle'",
which now gives much better output:

Downloading Graphics-tpr.225(fbs.221).mcd
Downloading Balloon-eem.23(fbs.22).mcd

and so on!

frank

Chris Muller-4

Re: CI works! (was Re: [squeak-dev] Logging progress during an update)

In reply to this post by Frank Shearar-3

See Installer>>#primMerge:. You may want to do something similar in
the CI scripts.

Then again, isn't CI supposed to tell us when something with the trunk
needs attention? If something needs merged then it need attention and
CI could/should report on that shouldn't it?

On Fri, Sep 20, 2013 at 6:29 AM, Frank Shearar <[hidden email]> wrote:

> On 17 September 2013 08:40, Frank Shearar <[hidden email]> wrote:
>> I really do need to take the time to look at that guy... So I should, for the moment, just need to catch the PIEs to log? I tried that but maybe I did it wrong. I'll take another run at it. We definitely do need a command line processor in trunk, at any rate. Loads of the CI work is working around our lack thereof.
>
> Well, I haven't managed to log updates, but I _have_ finally managed
> to fix the CI update scripts. A merge conflict caused an
> MCMergeBrowser to pop up and halt the world. CI assumed the task had
> hung (which it had, effectively), and hilarity ensued.
>
> http://build.squeak.org/job/SqueakTrunk/532/console shows a properly
> working update. (I have no idea where all those empty lines are coming
> from... unless they're progress indications?? Could be!)
>
> The script didn't just bail because an MCMergeResolutionRequest has a
> #defaultAction (to bring up the dialog). Since the script doesn't
> catch that exception, the #defaultAction triggers, popping up the
> dialog.
>
> Without having thought it through, one possible solution is to _never_
> create dialogs directly, but always through ToolSet. (So Monticello
> would extend ToolSet's API, for instance.) That way, a
> CommandLineToolSet could bail with a decent error message, while (in
> this case) the StandardToolSet could pop up a MCMergeBrowser.
>
> frank

Frank Shearar-3

Re: CI works! (was Re: [squeak-dev] Logging progress during an update)

On 20 September 2013 16:01, Chris Muller <[hidden email]> wrote:
> See Installer>>#primMerge:. You may want to do something similar in
> the CI scripts.

Yep!

> Then again, isn't CI supposed to tell us when something with the trunk
> needs attention? If something needs merged then it need attention and
> CI could/should report on that shouldn't it?

In this particular case the merge is entirely of my own making. Merges
will show up in the console. There may be other occasions when merge
conflicts might arise (although I can't think of any right now).

At the moment we can't abort the test run anyway, because we lack
Levente's #snapshot:andQuitWithExitCode: work in the Inbox. So while I
take your point, I'm happy with the current state of affairs, for the
moment at least.

frank

> On Fri, Sep 20, 2013 at 6:29 AM, Frank Shearar <[hidden email]> wrote:
>> On 17 September 2013 08:40, Frank Shearar <[hidden email]> wrote:
>>> I really do need to take the time to look at that guy... So I should, for the moment, just need to catch the PIEs to log? I tried that but maybe I did it wrong. I'll take another run at it. We definitely do need a command line processor in trunk, at any rate. Loads of the CI work is working around our lack thereof.
>>
>> Well, I haven't managed to log updates, but I _have_ finally managed
>> to fix the CI update scripts. A merge conflict caused an
>> MCMergeBrowser to pop up and halt the world. CI assumed the task had
>> hung (which it had, effectively), and hilarity ensued.
>>
>> http://build.squeak.org/job/SqueakTrunk/532/console shows a properly
>> working update. (I have no idea where all those empty lines are coming
>> from... unless they're progress indications?? Could be!)
>>
>> The script didn't just bail because an MCMergeResolutionRequest has a
>> #defaultAction (to bring up the dialog). Since the script doesn't
>> catch that exception, the #defaultAction triggers, popping up the
>> dialog.
>>
>> Without having thought it through, one possible solution is to _never_
>> create dialogs directly, but always through ToolSet. (So Monticello
>> would extend ToolSet's API, for instance.) That way, a
>> CommandLineToolSet could bail with a decent error message, while (in
>> this case) the StandardToolSet could pop up a MCMergeBrowser.
>>
>> frank