[Vm-dev] can I modify deploy scripts for Pharo?

[Ben Coman]

On Wed, Apr 5, 2017 at 8:44 PM, Esteban Lorenzano <estebanlm at gmail.com> wrote:
>
>
> On 5 Apr 2017, at 14:34, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:
>
> Hi Esteban,
> You mean moving more things up in opensmalltalk-vm?
>
> Yes that sounds the way to go,  (much more simple workflow).
>
>
> yes, what I do want is
> - to move and adapt:
> - pack-vm.sh
> - deploy-files.pharo.org-appveyor.sh
> - deploy-files.pharo.org.sh
> - deploy_key.enc
> - deploy-key.sh
>
> For your keys, it's not my expertise, but you could google something like  "deploy and sign in travis secret keys"
> https://docs.travis-ci.com/user/encryption-keys/
> http://stackoverflow.com/questions/9338428/using-secret-api-keys-on-travis-ci
>
>
> yeah, that does not work because how files.pharo.org is managed (not by us, so we cannot modify that part of the equation). So I need the keys… but I already made it work, so I just need to make that work also on osvm :)
>
> one thing I want to know is where to put those files… maybe a subdir “pharo-deploy”? or a ./deploy/pharo? (so in the future other flavours can put their specific files there?

Maybe "packaging" - since you may want to generate rpm, deb, snapcraft
packages and well as deploy those.

Or "distribution" - since in the same way RedHat/Debian are downstream
distributions of Linux,
Squeak/Pharo/Cuis/Newspeak might be considered downstream
distributions of OpenSmalltalk.

Or "dialect" - since that is how we often refer to Pharo/Squeak etc...

But actually "deploy" probably encompasses those cases reasonably well.
But rather than "pharo-deploy", if located in the root folder it sould follow
 "build.platformXXX" pattern to be "deploy.pharo"

./deploy/pharo versus ./deploy.pharo would maybe depend or whether in
future there is much common with the deploy scripts between dialects.


btw, it might nice to have somewhere to consolidate duplication like this...

build.win32x86/squeak.cog.v3/squeak.ico
build.win32x86/squeak.cog.spur/squeak.ico
build.win32x86/squeak.cog.spur.lowcode/squeak.ico
build.win32x86/squeak.stack.v3/squeak.ico
build.win32x86/squeak.stack.spur/squeak.ico
build.win32x86/pharo.cog.spur/Pharo.ico
build.win32x86/pharo.cog.spur.lowcode/Pharo.ico
build.win64x64/squeak.stack.spur/squeak.ico
build.win64x64/squeak.cog.spur/squeak.ico
build.win64x64/pharo.stack.spur/Pharo.ico
platforms/win32/misc/squeak.ico
platforms/iOS/vm/OSX/Squeak.icns
platforms/Mac OS/Resources/Squeak.icns

build.linux32x86/editpharoinstall.sh
build.linux64x64/editpharoinstall.sh
build.linux32ARMv6/editpharoinstall.sh

build.linux32x86/editnewspeakinstall.sh
build.linux64x64/editnewspeakinstall.sh
build.linux32ARMv6/editnewspeakinstall.sh
build.linux32ARMv7/editnewspeakinstall.sh


cheers -ben

>
> Esteban
>
>
> etc…
>
>
> 2017-04-05 8:27 GMT+02:00 Esteban Lorenzano <estebanlm at gmail.com>:
>>
>>
>> Hi guys,
>>
>> I was reading the other thread this morning and I figure out I have an easy way of solve all problems (besides that damn String primitive problem that still needs to be fixed).
>> This is the thing:
>>
>> If I can add special deploy script for Pharo (with my keys, so is not soooo cool, but is not so bad either), to deploy osvm build VMs into Pharo infrastructure, then I can
>>
>> 1) use that as our “stable” builds.
>> 2) keep having the rest of the process unaltered, so we will keep the validation infrastructure and the nightly builds (that we call “latest”).
>>
>> and then, everything will be “as it should be”.
>>
>> what do you think, can I go ahead and modify that part?
>>
>> Esteban
>
>
>
>