can I modify deploy scripts for Pharo?

On Wed, Apr 5, 2017 at 8:44 PM, Esteban Lorenzano <[hidden email]> wrote:
>
>
> On 5 Apr 2017, at 14:34, Nicolas Cellier <[hidden email]> 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 <[hidden email]>:
>>
>>
>> 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
>
>
>
>

On 5 Apr 2017, at 22:46, Fabio Niephaus <[hidden email]> wrote:

On Wed, Apr 5, 2017 at 6:07 PM Ben Coman <[hidden email]> wrote:

On Wed, Apr 5, 2017 at 8:44 PM, Esteban Lorenzano <[hidden email]> wrote:

>
>
> On 5 Apr 2017, at 14:34, Nicolas Cellier <[hidden email]> 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.

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 <[hidden email]>:
>>
>>
>> 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
>
>
>
>