Add RowanLoadSpec and friends to SmalltalkCI

[dalehenrich]

See the SmalltalkCI for Rowan project board for an overview of the activities and progress. Here are the key points from the SmalltalkCI card as of time this issue was created:

• port smalltalkCI to GemStone/S in the absence of GsDevKit/GLASS
  • partition Monticello/Metacello/Gofer packages as they will not be supported in GemStone kernel
  • use Rowan to load SmalltalkCI into GemStone kernel
  • get basic SmalltalkCI tests to pass
• implement SCIRowanLoadSpec and friends

At this point in time, I have not made any major decisions other than the fact that Monticello/Metacello/Gofer will not be supported in the GemStone kernel, so right now the biggest direct impact on SmalltalkCI would be the repackaging that would be required.

I've already split out Monticello/Metacello/Gofer support into separate packages (example package here). With the current package structure, I've been able to load SmalltalkCI into a standard GemStone extent (no GLASS/GSDevKit) using Rowan and am in the process of getting the tests to pass.

I have not quite worked out what the SCIRowanLoadSpec but I am considering that it will resemble the SCICustomScript in that I expect there to be multiple load steps involved (each as as a different GemStone user).

@fniephaus, please feel free to jump in and comment on the changes that I've been making so far and anything that you have concerns about (I promise not to YELL:)...
Since I am touching GsDevKit_home as well as SmalltalkCI, I do intend to remove all of the deprecated API calls that I have been using, so if you have some favorite bugs that you'd like me to address, please list them here ... one caveat is that I don't intend to do any Metacello work in the short term (except straight bugfixes) ...

I just hit a major milestone yesterday, so I'm not quite under the intense pressure that I have been under for awhile, but the next major milestone is coming up in a couple of months, so I am not completely out of the woods yet:)

[fniephaus]

That's great news! Will have a look tomorrow :)

[fniephaus]

Sorry, haven't had enough time to look at your changes yet. But I do remember what I wanted to change/fix which requires GsDevKit to be changed as well. The #test: API tests and closes the image. I'd like to separate this into two steps. Maybe, we also need something like #test:andSaveOnError: and then by default, "#test: config" calls "#test: config andSaveOnError: false".
I hope I can work something like this out next week, so that we can get this done while you have some time :)

[dalehenrich]

That sounds great ... I'll have to refresh my memory in this area as well, to see what GemStone has been doing, since the concept of closing and saving the image is somewhat foreign to GemStone --- a commit is all that is needed to save image ... I seem to recall that there was something about quitting the image that was troublesome for GemStone?

Maybe some pointers to the GsDevKIt changes that you were thinking about?

[fniephaus]

GitHub's search revealed these two links for senders of SmalltalkCI>>#test:*:

• https://github.com/GsDevKit/GsDevKit_home/blob/32da47eda74c5d4fa154bb95c193d998a6258ce9/bin/smalltalkCI#L187
• https://github.com/GsDevKit/GsDevKit_home/blob/32da47eda74c5d4fa154bb95c193d998a6258ce9/bin/createStone#L304

I think instead of saving the image, smalltalkCI does a commit in GemStone. So in theory, it should just be enough to add that commit right after these two lines. But we need to check whether that's correct.

[dalehenrich]

I took a quick look at the #test: method in SmalltalkCI and I didn't see anything related to #saveImage: ... is this something that you are planning to add or should I be seeing #saveImage:?

[fniephaus]

@dalehenrich I think it's not so much GemStone, but the Pharo clients that need to be adjusted. I'll try to refactor smalltalkCI this week and then we can see where things break on your side and fix them. Obviously, I won't do any of this on master branches ;)

[fniephaus]

Hi @dalehenrich, sorry for the delay. Please have a look at the non-closing-test branch and compare it to master to get an idea what I want to do. If you could make sure that branch works fine with GsDevKit, that'd be great!

Also, I found our previous conversion on this, it's issue #242. Please note that I've also been versioning smalltalkCI in the last year, so maybe it'd be a good idea to start locking smalltalkCI versions in GsDevKit when we are done with this and things start to slow down again.

Just a quick reminder: I've got some cycles to work on this until the end of the week, I'm afraid I won't have much time to work on this in September as mentioned previously.

[dalehenrich]

@fniephaus ... I'm also on somewhat of a tight leash as now I've got my ESUG presentation to write and will be gone with ESUG for two weeks in September ... I have a Rowan issue that I need to make progress on (only one at the moment:), but I will try to squeeze in some SmalltalkCI work this week ...

[fniephaus]

Apparently, all smalltalkCI builds passed, but I just pushed another version that changes the return value of #test and #load. Shouldn't affect smalltalkCI builds though, so please test this with GsDevKit.

[dalehenrich]

... okay .. I've gotten around to testing the non-closing-test and I do hit errors (that I can and will fix) when I try to build gsdevkit clients when using this branch...

I think I want to separate the work for the non-closing-test branch from the Rowan port. That way I can push out GsDevKit_home support for the new SmalltalkCI version without having to synchronize with the Rowan support ...

At this point I cannot rell if I will need to add private methods to SmalltalkCI or simply change GsDevKit_home ... as an example the error that I hit creating Pharo clients using the non-closing-test is a MNU: False(Object)>>doesNotUnderstand: #compatibleConfigurationsFor: ... I haven't characterized the problem, so I don't know which of your changes has caused this issue (if any), however, if I run using the master branch the Pharo client build finishes without errors ...

At a minimum I expect to add client tests to SmalltalkCI that exercises the code that is failing in my GsDevKit_home tests ...

[dalehenrich]

I've opened Issue #392 to track issues I run into using the non-closing-test branch, so that this issue can stay focused on adding Rowan support to SmalltalkCI

[fniephaus]

Thanks, that makes sense :)

[dalehenrich]

Closing in favor of #597