Quantcast

can I modify deploy scripts for Pharo?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

can I modify deploy scripts for Pharo?

EstebanLM
 
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: can I modify deploy scripts for Pharo?

Nicolas Cellier
 
Hi Esteban,
You mean moving more things up in opensmalltalk-vm?
Yes that sounds the way to go,  (much more simple workflow).
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
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: can I modify deploy scripts for Pharo?

EstebanLM
 

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 is files.pharo.org 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?

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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: can I modify deploy scripts for Pharo?

Ben Coman
 
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
>
>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: can I modify deploy scripts for Pharo?

fniephaus
 
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.

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.

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
>
>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: can I modify deploy scripts for Pharo?

EstebanLM
 

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
>
>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: can I modify deploy scripts for Pharo?

fniephaus
 
On Wed, Apr 5, 2017 at 10:53 PM Esteban Lorenzano <[hidden email]> wrote:
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) :)

Sure, just wanted to make sure that we also keep the current setup :)
 

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
>
>
>
>
Loading...