> 1. It’s worth mention that for starting a server image you can also > install/hook to the #startUp: message in the right class with the benefit of > not relying in an external script that might generate a problem not tested by > the image builder or CI environment (which is what I’m doing BTW)
Can you precise what you mean by image builder / CI environment? > 2. it currently doesn’t work. You can send an .st script alright and the save > will be ignored (so you have to do that in two commands not one) Yes, I wanted to tell you that you cannot execute multiple commands at once. I think that is your original cause of errors (note this is partially document in the --help). Additionally, yes, the current CLI is very permissive, aka trailing arguments are just ignored and not reported. > 3. You don’t have a server if you don’t have its image prepared first. So, to > be “reasonable" you have to (a) break the flow of the experience and (b) > break the consistency with the default script behaviour. I don't understand what you mean here. If you run a script, you can control everything in there: - installing sofware - saving the image - quiting the image So technically you don't need the save command or anything, you rely on Pharo. The other option is to rely on several separate external commands, which will give you a more bash-like behavior. Typically this is what we do on jenkins to avoid the tedious task to maintain external scripts: - install new software with the #configuration command - save the image with a different name - start the server using the #eval command > Both at the same time. If you want to decree that the current behaviour is > reasonable you have to do both: disregard the flow of the experience and the > consistency of the pharo script-ish default behaviour. But that only after > you fix the bug
signature.asc
Description: Message signed with OpenPGP using GPGMail
