[Pharo-project] Jenkins: build scripts are now in public repository
Hello, i put an initial version of build scripts which used by hudson/jenkins to gitorious: git://gitorious.org/pharo-build/pharo-build.git I modified build.sh script to work well with this set up. So, instead of locating scripts on slave, a job takes them from "Scripts download" job, which just takes them from git. (https://ci.lille.inria.fr/pharo/job/Scripts%20download/) The rest is as usual - run scripts and see what happens. I added a job to build Pharo 1.4 using new set up.. after couple bugs, it seems to be working well: https://ci.lille.inria.fr/pharo/job/new%20scripts%20Pharo%201.4/ so, we should migrate all jobs to use these scripts , which is publicly available through git.. so, we don't need to manually manage these files on server anymore. -- Best regards, Igor Stasenko AKA sig.
What I great change. I think I have asked Marcus about them like 10 times :) On Mon, Jul 11, 2011 at 7:19 PM, Igor Stasenko <siguctua@gmail.com> wrote:
Hello,
i put an initial version of build scripts which used by hudson/jenkins to gitorious:
git://gitorious.org/pharo-build/pharo-build.git
I modified build.sh script to work well with this set up. So, instead of locating scripts on slave, a job takes them from "Scripts download" job, which just takes them from git. (https://ci.lille.inria.fr/pharo/job/Scripts%20download/)
The rest is as usual - run scripts and see what happens. I added a job to build Pharo 1.4 using new set up.. after couple bugs, it seems to be working well: https://ci.lille.inria.fr/pharo/job/new%20scripts%20Pharo%201.4/
so, we should migrate all jobs to use these scripts , which is publicly available through git.. so, we don't need to manually manage these files on server anymore.
-- Best regards, Igor Stasenko AKA sig.
-- Mariano http://marianopeck.wordpress.com
On 11 July 2011 19:33, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
What I great change. I think I have asked Marcus about them like 10 times :)
So, i think you asked for a reason? :) Because now you have commit rights to this repository, nothing prevents you from doing what you wanted to do :) The changes are quite simple: - avoid using absolute paths (instead use $WORKSPACE) environment variable all scripts are starting from: if [ -z "$WORKSPACE" ] ; then WORKSPACE=`pwd` fi so, you can run them on your local machine, and they will work same on server. Of course if you don't make stupid mistakes... ( bah it's so easy to look like an idiot with these bash scripts. I have bash/sh !!!) When you need to invoke VM , use PHARO_VM environment variable. Which is set on slave to point to VM. Like: exec "$PHARO_VM" $PHARO_PARAM "$OUTPUT_IMAGE" "$OUTPUT_SCRIPT" -headless Of course, for testing freshly built VMs it may point to another place, but scripts will remain same. (tomorrow i will start migrating VM jobs from hudson to jenkins) Jenkins is more appeal and seems to be less buggy. :) -- Best regards, Igor Stasenko AKA sig.
Igor, please publish then server versions of build scripts like build13.sh, build-kernel.sh etc. too. -- Pavel On Mon, Jul 11, 2011 at 7:47 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 11 July 2011 19:33, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
What I great change. I think I have asked Marcus about them like 10 times :)
So, i think you asked for a reason? :) Because now you have commit rights to this repository, nothing prevents you from doing what you wanted to do :)
The changes are quite simple: Â - avoid using absolute paths (instead use $WORKSPACE) environment variable all scripts are starting from:
if [ -z "$WORKSPACE" ] ; then     WORKSPACE=`pwd` fi
so, you can run them on your local machine, and they will work same on server. Of course if you don't make stupid mistakes... ( bah it's so easy to look like an idiot with these bash scripts. I have bash/sh !!!)
When you need to invoke VM , use PHARO_VM environment variable. Which is set on slave to point to VM. Like: exec "$PHARO_VM" $PHARO_PARAM "$OUTPUT_IMAGE" "$OUTPUT_SCRIPT" -headless
Of course, for testing freshly built VMs it may point to another place, but scripts will remain same.
(tomorrow i will start migrating VM jobs from hudson to jenkins) Jenkins is more appeal and seems to be less buggy. :)
-- Best regards, Igor Stasenko AKA sig.
On 12 July 2011 10:58, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Igor,
please publish then server versions of build scripts like build13.sh,
build.sh on git is based on build13.sh. The old build.sh was different in a way how it handles image stalls. There was loop waiting for output from image. And if nothing happens it kills VM process. Now since in 1.3 this is much less likely to happen (because it using non-interactive ui manager), we removed that.
build-kernel.sh etc. too.
it almost the same as build.sh.. but there are some difference. i started to examine it yesterday but then came home :)
-- Pavel
On Mon, Jul 11, 2011 at 7:47 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 11 July 2011 19:33, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
What I great change. I think I have asked Marcus about them like 10 times :)
So, i think you asked for a reason? :) Because now you have commit rights to this repository, nothing prevents you from doing what you wanted to do :)
The changes are quite simple: Â - avoid using absolute paths (instead use $WORKSPACE) environment variable all scripts are starting from:
if [ -z "$WORKSPACE" ] ; then     WORKSPACE=`pwd` fi
so, you can run them on your local machine, and they will work same on server. Of course if you don't make stupid mistakes... ( bah it's so easy to look like an idiot with these bash scripts. I have bash/sh !!!)
When you need to invoke VM , use PHARO_VM environment variable. Which is set on slave to point to VM. Like: exec "$PHARO_VM" $PHARO_PARAM "$OUTPUT_IMAGE" "$OUTPUT_SCRIPT" -headless
Of course, for testing freshly built VMs it may point to another place, but scripts will remain same.
(tomorrow i will start migrating VM jobs from hudson to jenkins) Jenkins is more appeal and seems to be less buggy. :)
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
On Tue, Jul 12, 2011 at 2:34 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 12 July 2011 10:58, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Igor,
please publish then server versions of build scripts like build13.sh,
build.sh on git is based on build13.sh. The old build.sh was different in a way how it handles image stalls. There was loop waiting for output from image. And if nothing happens it kills VM process. Now since in 1.3 this is much less likely to happen (because it using non-interactive ui manager), we removed that.
build-kernel.sh etc. too.
it almost the same as build.sh.. but there are some difference. i started to examine it yesterday but then came home :)
I wrote it so I know how it differs ;-) I only want to see the current version used on server and make it available to others -- Pavel
-- Pavel
On Mon, Jul 11, 2011 at 7:47 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 11 July 2011 19:33, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
What I great change. I think I have asked Marcus about them like 10 times :)
So, i think you asked for a reason? :) Because now you have commit rights to this repository, nothing prevents you from doing what you wanted to do :)
The changes are quite simple: Â - avoid using absolute paths (instead use $WORKSPACE) environment variable all scripts are starting from:
if [ -z "$WORKSPACE" ] ; then     WORKSPACE=`pwd` fi
so, you can run them on your local machine, and they will work same on server. Of course if you don't make stupid mistakes... ( bah it's so easy to look like an idiot with these bash scripts. I have bash/sh !!!)
When you need to invoke VM , use PHARO_VM environment variable. Which is set on slave to point to VM. Like: exec "$PHARO_VM" $PHARO_PARAM "$OUTPUT_IMAGE" "$OUTPUT_SCRIPT" -headless
Of course, for testing freshly built VMs it may point to another place, but scripts will remain same.
(tomorrow i will start migrating VM jobs from hudson to jenkins) Jenkins is more appeal and seems to be less buggy. :)
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
On 12 July 2011 16:58, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
On Tue, Jul 12, 2011 at 2:34 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 12 July 2011 10:58, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Igor,
please publish then server versions of build scripts like build13.sh,
build.sh on git is based on build13.sh. The old build.sh was different in a way how it handles image stalls. There was loop waiting for output from image. And if nothing happens it kills VM process. Now since in 1.3 this is much less likely to happen (because it using non-interactive ui manager), we removed that.
build-kernel.sh etc. too.
it almost the same as build.sh.. but there are some difference. i started to examine it yesterday but then came home :)
I wrote it so I know how it differs ;-) I only want to see the current version used on server and make it available to others
Yes. i will convert your script to use $WORKSPACE var and push it to git. (and update job accordingly). Once it there you will be able to modify it by yourself. -- Best regards, Igor Stasenko AKA sig.
Great, thank you, what about to create wiki page with configuration descriptions? What exact VM version does the CI server use? -- Pavel On Mon, Jul 11, 2011 at 7:19 PM, Igor Stasenko <siguctua@gmail.com> wrote:
Hello,
i put an initial version of build scripts which used by hudson/jenkins to gitorious:
git://gitorious.org/pharo-build/pharo-build.git
I modified build.sh script to work well with this set up. So, instead of locating scripts on slave, a job takes them from "Scripts download" job, which just takes them from git. (https://ci.lille.inria.fr/pharo/job/Scripts%20download/)
The rest is as usual - run scripts and see what happens. I added a job to build Pharo 1.4 using new set up.. after couple bugs, it seems to be working well: https://ci.lille.inria.fr/pharo/job/new%20scripts%20Pharo%201.4/
so, we should migrate all jobs to use these scripts , which is publicly available through git.. so, we don't need to manually manage these files on server anymore.
-- Best regards, Igor Stasenko AKA sig.
On 11 July 2011 19:53, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Great, thank you,
what about to create wiki page with configuration descriptions?
what you meant by configuration descriptions? you mean job descriptions? Like: "This job runs a, b then c" ?
What exact VM version does the CI server use?
pretty old one: ./squeak -version 4.4.7-2357 #1 XShm Sun Jan 23 18:17:31 PST 2011 gcc 4.3.2 Linux vps2.piumarta.com 2.6.18-028stab053.10-ent #1 SMP Thu Feb 28 20:34:08 MSK 2008 i686 GNU/Linux plugin path: /builds/vm/lib/squeak/4.4.7-2357 [default: /builds/vm/lib/squeak/4.4.7-2357/]
-- Pavel
On Mon, Jul 11, 2011 at 7:19 PM, Igor Stasenko <siguctua@gmail.com> wrote:
Hello,
i put an initial version of build scripts which used by hudson/jenkins to gitorious:
git://gitorious.org/pharo-build/pharo-build.git
I modified build.sh script to work well with this set up. So, instead of locating scripts on slave, a job takes them from "Scripts download" job, which just takes them from git. (https://ci.lille.inria.fr/pharo/job/Scripts%20download/)
The rest is as usual - run scripts and see what happens. I added a job to build Pharo 1.4 using new set up.. after couple bugs, it seems to be working well: https://ci.lille.inria.fr/pharo/job/new%20scripts%20Pharo%201.4/
so, we should migrate all jobs to use these scripts , which is publicly available through git.. so, we don't need to manually manage these files on server anymore.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
On Mon, Jul 11, 2011 at 8:00 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 11 July 2011 19:53, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Great, thank you,
what about to create wiki page with configuration descriptions?
what you meant by configuration descriptions? you mean job descriptions? Like: "This job runs a, b then c" ?
No, I mean description of the job configuration together with installation instructions by Lukas (https://github.com/renggli/builder), something like: Project name: PharoKernel-Core-1.4 Source Code Management: none Execute shell Command: /var/lib/jenkins/builder/build-kernel.sh -t PharoCore-1.4 -c exportAccuny -i PharoKernel-Gofer-1.4 -s loadCore -s initCore -o PharoKernel-Core-1.4 Archive the artifacts: **/*.image, **/*.changes etc. So everyone can have the same CI settings and simply create own. -- Pavel
What exact VM version does the CI server use?
pretty old one:
./squeak -version 4.4.7-2357 #1 XShm Sun Jan 23 18:17:31 PST 2011 gcc 4.3.2 Linux vps2.piumarta.com 2.6.18-028stab053.10-ent #1 SMP Thu Feb 28 20:34:08 MSK 2008 i686 GNU/Linux plugin path: /builds/vm/lib/squeak/4.4.7-2357 [default: /builds/vm/lib/squeak/4.4.7-2357/]
-- Pavel
On Mon, Jul 11, 2011 at 7:19 PM, Igor Stasenko <siguctua@gmail.com> wrote:
Hello,
i put an initial version of build scripts which used by hudson/jenkins to gitorious:
git://gitorious.org/pharo-build/pharo-build.git
I modified build.sh script to work well with this set up. So, instead of locating scripts on slave, a job takes them from "Scripts download" job, which just takes them from git. (https://ci.lille.inria.fr/pharo/job/Scripts%20download/)
The rest is as usual - run scripts and see what happens. I added a job to build Pharo 1.4 using new set up.. after couple bugs, it seems to be working well: https://ci.lille.inria.fr/pharo/job/new%20scripts%20Pharo%201.4/
so, we should migrate all jobs to use these scripts , which is publicly available through git.. so, we don't need to manually manage these files on server anymore.
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
On 11 July 2011 20:08, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
On Mon, Jul 11, 2011 at 8:00 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 11 July 2011 19:53, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Great, thank you,
what about to create wiki page with configuration descriptions?
what you meant by configuration descriptions? you mean job descriptions? Like: "This job runs a, b then c" ?
No, I mean description of the job configuration together with installation instructions by Lukas (https://github.com/renggli/builder), something like:
Project name: PharoKernel-Core-1.4 Source Code Management: none Execute shell Command: /var/lib/jenkins/builder/build-kernel.sh -t PharoCore-1.4 -c exportAccuny -i PharoKernel-Gofer-1.4 -s loadCore -s initCore -o PharoKernel-Core-1.4 Archive the artifacts: **/*.image, **/*.changes etc.
So everyone can have the same CI settings and simply create own.
Why forcing people to do additional manual work? I just installed a plugin (https://wiki.jenkins-ci.org/display/JENKINS/Extended+Read+Permission+Plugin) so anonymous users can see the jobs configurations like this one: https://ci.lille.inria.fr/pharo/job/new%20scripts%20Pharo%201.4/configure
-- Pavel
-- Best regards, Igor Stasenko AKA sig.
On Mon, Jul 11, 2011 at 8:28 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 11 July 2011 20:08, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
On Mon, Jul 11, 2011 at 8:00 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 11 July 2011 19:53, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
Great, thank you,
what about to create wiki page with configuration descriptions?
what you meant by configuration descriptions? you mean job descriptions? Like: "This job runs a, b then c" ?
No, I mean description of the job configuration together with installation instructions by Lukas (https://github.com/renggli/builder), something like:
Project name: PharoKernel-Core-1.4 Source Code Management: none Execute shell Command: /var/lib/jenkins/builder/build-kernel.sh -t PharoCore-1.4 -c exportAccuny -i PharoKernel-Gofer-1.4 -s loadCore -s initCore -o PharoKernel-Core-1.4 Archive the artifacts: **/*.image, **/*.changes etc.
So everyone can have the same CI settings and simply create own.
Why forcing people to do additional manual work? I just installed a plugin (https://wiki.jenkins-ci.org/display/JENKINS/Extended+Read+Permission+Plugin) so anonymous users can see the jobs configurations like this one: https://ci.lille.inria.fr/pharo/job/new%20scripts%20Pharo%201.4/configure
coool :-) -- Pavel
Great idea. Stef On Jul 11, 2011, at 7:19 PM, Igor Stasenko wrote:
Hello,
i put an initial version of build scripts which used by hudson/jenkins to gitorious:
git://gitorious.org/pharo-build/pharo-build.git
I modified build.sh script to work well with this set up. So, instead of locating scripts on slave, a job takes them from "Scripts download" job, which just takes them from git. (https://ci.lille.inria.fr/pharo/job/Scripts%20download/)
The rest is as usual - run scripts and see what happens. I added a job to build Pharo 1.4 using new set up.. after couple bugs, it seems to be working well: https://ci.lille.inria.fr/pharo/job/new%20scripts%20Pharo%201.4/
so, we should migrate all jobs to use these scripts , which is publicly available through git.. so, we don't need to manually manage these files on server anymore.
-- Best regards, Igor Stasenko AKA sig.
Hi Igor. I was looking in the scripts and I found that the version of Pharo1.4 is "hardcoded": https://gitorious.org/pharo-build/pharo-build/blobs/master/pharo-shell-scrip... Maybe you can get it from a static url like http://www.pharo-project.org/pharo-download/unstable-core or fetch the previous (successful ?) one from hudson? On Mon, Jul 11, 2011 at 7:19 PM, Igor Stasenko <siguctua@gmail.com> wrote:
Hello,
i put an initial version of build scripts which used by hudson/jenkins to gitorious:
git://gitorious.org/pharo-build/pharo-build.git
I modified build.sh script to work well with this set up. So, instead of locating scripts on slave, a job takes them from "Scripts download" job, which just takes them from git. (https://ci.lille.inria.fr/pharo/job/Scripts%20download/)
The rest is as usual - run scripts and see what happens. I added a job to build Pharo 1.4 using new set up.. after couple bugs, it seems to be working well: https://ci.lille.inria.fr/pharo/job/new%20scripts%20Pharo%201.4/
so, we should migrate all jobs to use these scripts , which is publicly available through git.. so, we don't need to manually manage these files on server anymore.
-- Best regards, Igor Stasenko AKA sig.
-- Mariano http://marianopeck.wordpress.com
participants (4)
-
Igor Stasenko -
Mariano Martinez Peck -
Pavel Krivanek -
Stéphane Ducasse