gtoolkit icon indicating copy to clipboard operation
gtoolkit copied to clipboard

Release fails due to error in MCDefinitionIndex>>definitionLike:ifPresent:ifAbsent:

Open chisandrei opened this issue 3 years ago • 5 comments
trafficstars

Seems like we are running into the https://github.com/pharo-project/pharo/issues/10974 when releasing.

2022-03-18T10:27:41.474823-04:00 GtRlExecuteActionSignal 19 Executed action: Compile baseline BaselineOfGToolkitGleam gtoolkit-gleam
2022-03-18T10:27:41.482359-04:00 GtRlExecuteActionSignal 20 Executed action: Export .baseline-metadata.ston gtoolkit-gleam
2022-03-18T10:27:41.492023-04:00 GtRlExecuteActionSignal 21 Executed action: Commit changes on branch #release and tag commit with 'v0.8.32' gtoolkit-gleamIceNode(.baseline-metadata.ston)IceNode(baseline:)
2022-03-18T10:27:41.651322-04:00 GtRlExecuteActionSignal 22 Executed action: Merge reference branch #main to release branch #release gtoolkit-glutin[31m#description was sent to nil
[0mUndefinedObject(Object)>>doesNotUnderstand: #description
UndefinedObject>>doesNotUnderstand: #description
MCDefinitionIndex>>definitionLike:ifPresent:ifAbsent:
MCPatcher>>modifyDefinition:to:
IceClassDefinition>>addModification:toPatcher:
IceMCSnapshotPatchVisitor>>visitModification:
IceModification>>accept:
IceMCSnapshotPatchVisitor>>visitNonConflictingOperation:
IceNonConflictingOperation>>accept:
[ 
		anIceNode value accept: self ] in IceMCSnapshotPatchVisitor(IceTreeVisitor)>>visitTreeNode: in Block: [ ...
FullBlockClosure(BlockClosure)>>ensure:
IceMCSnapshotPatchVisitor(IceTreeVisitor)>>withNode:do:
IceMCSnapshotPatchVisitor(IceTreeVisitor)>>visitTreeNode:
IceNode>>accept:
[ :each | each accept: self ] in IceMCSnapshotPatchVisitor(IceTreeVisitor)>>visitChildrenOf: in Block: [ :each | each accept: self ]
Array(SequenceableCollection)>>do:
IceNode(IceAbstractNode)>>childrenDo:
IceMCSnapshotPatchVisitor(IceTreeVisitor)>>visitChildrenOf:
IceMCSnapshotPatchVisitor>>visitNoModification:
IceNoModification>>accept:
IceMCSnapshotPatchVisitor>>visitNonConflictingOperation:
IceNonConflictingOperation>>accept:
[ 
		anIceNode value accept: self ] in IceMCSnapshotPatchVisitor(IceTreeVisitor)>>visitTreeNode: in Block: [ ...
FullBlockClosure(BlockClosure)>>ensure:
IceMCSnapshotPatchVisitor(IceTreeVisitor)>>withNode:do:
IceMCSnapshotPatchVisitor(IceTreeVisitor)>>visitTreeNode:
IceNode>>accept:
IceGitWorkingCopyUpdateVisitor>>visitPackage:
IcePackageDefinition>>accept:
IceGitWorkingCopyUpdateVisitor>>visitNoModification:

chisandrei avatar Mar 18 '22 14:03 chisandrei

I ran into this as well under circumstances similar to those described in the issue you linked to. I posted a workaround there.

seandenigris avatar Mar 18 '22 15:03 seandenigris

@seandenigris I guess the workaround would be aDefinition ifNil: [ ^ errorBlock value ] as aDefinition is already nil.

Screenshot 2022-03-18 at 17 27 58

chisandrei avatar Mar 18 '22 16:03 chisandrei

I also tried something like below in MCPatcher>>modifyDefinition:to:

baseDefinition ifNil: [
		^ self addDefinition: targetDefinition ].

and

baseDefinition ifNil: [
		^ self  ].

In both cases the trait was added ok on the class side. The first version is what would have been executed before the fix in https://github.com/pharo-project/pharo/issues/10974.

chisandrei avatar Mar 18 '22 16:03 chisandrei

As a first try for a workaround I went with the first option above:

baseDefinition ifNil: [
		^ self addDefinition: targetDefinition ].

Mostly to behave as before. Could still be wrong and might be that ignoring the definition is the best solution.

chisandrei avatar Mar 18 '22 16:03 chisandrei

@seandenigris I guess the workaround would be aDefinition ifNil: [ ^ errorBlock value ] as aDefinition is already nil.

ah yes I had an extra send in there. Good catch

seandenigris avatar Mar 18 '22 17:03 seandenigris