On 20 September 2013 16:01, Chris Muller <ma.chris.m at gmail.com> 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 <frank.shearar at gmail.com> wrote:
>> On 17 September 2013 08:40, Frank Shearar <frank.shearar at gmail.com> 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