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

[Esteban Lorenzano]

> On 5 Apr 2017, at 22:46, Fabio Niephaus <lists at fniephaus.com> wrote:
> 
> On Wed, Apr 5, 2017 at 6:07 PM Ben Coman <btc at openinworld.com <mailto:btc at openinworld.com>> wrote:
> 
> On Wed, Apr 5, 2017 at 8:44 PM, Esteban Lorenzano <estebanlm at gmail.com <mailto:estebanlm at gmail.com>> wrote:
> >
> >
> > On 5 Apr 2017, at 14:34, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com <mailto: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 <http://deploy-files.pharo.org-appveyor.sh/>
> > - deploy-files.pharo.org.sh <http://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/ <https://docs.travis-ci.com/user/encryption-keys/>
> > http://stackoverflow.com/questions/9338428/using-secret-api-keys-on-travis-ci <http://stackoverflow.com/questions/9338428/using-secret-api-keys-on-travis-ci>
> >
> >
> > yeah, that does not work because how files.pharo.org <http://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.
> 
> I'd prefer a ./deploy/ directory with a file or a subdirectory for each deployment target, e.g. ./deploy/bintray.sh and ./deploy/pharo/ (if you need to have multiple deployment scripts for pharo). Then we could have common scripts in ./deploy/common.sh or ./deploy/common/ (if necessary).
> If we follow the build.platformXXX pattern for deployments, we eventually end up with a bunch of more directories in the root directory and that already has lots of subdirectories.

ok

> 
> Also, I think it'd be great if Pharo remains part of the current deployment set. But I of course understand that you might additionally deploy the vm to some other deployment target.

We have out infrastructure requirements and we need to deploy to our servers. 
But I do not see why it can not be both (and I never said otherwise) :)

Esteban


> 
> Fabio
> 
>  
> 
> 
> 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 <mailto: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
> >
> >
> >
> >

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170405/5ba9f509/attachment-0001.html>