- Pharo-users - lists.pharo.org

Re: [Pharo-users] Units package

by Marcus Denker

On Jul 26, 2013, at 9:34 AM, phil(a)highoctane.be wrote: > In my application, I need to work with units (which I have to integrate in Seaside-Magritte 3). > > So, I looked around and after a while found > > http://www.smalltalkhub.com/#!/~MarcusDenker/Units > > Tests are green on 2.0 and it looks like it will do what I need. > > Pretty cool package, worth a chapter somewhere. > > Is there any doc on this except the code itself? > No, sadly not. Yes, it should be documentedâ¦ :-) And I need to add a configuration. Marcus

July 26, 2013

Units package

by phil＠highoctane.be

In my application, I need to work with units (which I have to integrate in Seaside-Magritte 3). So, I looked around and after a while found http://www.smalltalkhub.com/#!/~MarcusDenker/Units Tests are green on 2.0 and it looks like it will do what I need. Pretty cool package, worth a chapter somewhere. Is there any doc on this except the code itself? Phil

July 26, 2013

Re: [Pharo-users] Your vm is too oldâ¦.

by Tudor Girba

Oops. Sorry for creating confusions. Doru On Jul 25, 2013, at 1:55 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 25 July 2013 12:05, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> The workaround at the image level was needed only until we got the VM >> working. The details about the workaround are here: >> https://pharo.fogbugz.com/f/cases/10395/ >> >> I was sure that in the meantime, the problem was solved in the VM as well, >> but I cannot trace that information. Perhaps it is not. Esteban? >> > > Last time i discussed with Esteban about it, he said that he don't > knows where the problem in VM, > neither me. > > >> Cheers, >> Doru >> >> >> On Thu, Jul 25, 2013 at 9:13 AM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> >>> >>> On Jul 25, 2013, at 9:08 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> This was a problem that we also had (when working in Moose), and Esteban >>> fixed it (first the workaround in the image, and then in the VM). We are >>> using this VM since some months now and the problem did not resurface. >>> >>> That is why I know it is fixed in the latest stable PharoVM. >>> >>> >>> Ok what igor is probably meaning is that we would prefer to get the system >>> running without having to have a workaround at the image level. >>> >>> >>> Cheers, >>> Doru >>> >>> >>> On Thu, Jul 25, 2013 at 9:03 AM, Norbert Hartl <norbert(a)hartl.name> wrote: >>>> >>>> Doru, >>>> >>>> I'm sorry but I was mistaken somehow. I tried always to use the newest >>>> VM. I just downloaded a new vm a few minutes ago and now I cannot reproduce >>>> the problem anymore. That doesn't mean it won't appear anymore but I'll work >>>> with the pharo vm and see if it comes back. >>>> >>>> thanks, >>>> >>>> Norbert >>>> >>>> Am 24.07.2013 um 22:46 schrieb Tudor Girba <tudor(a)tudorgirba.com>: >>>> >>>>> Use the latest stable VM. It should solve the problem. >>>>> >>>>> Doru >>>>> >>>>> >>>>> On Jul 24, 2013, at 10:34 PM, Norbert Hartl <norbert(a)hartl.name> wrote: >>>>> >>>>>> >>>>>> >>>>>> Am 24.07.2013 um 18:21 schrieb StÃ©phane Ducasse >>>>>> <stephane.ducasse(a)inria.fr>: >>>>>> >>>>>>> >>>>>>> On Jul 24, 2013, at 5:13 PM, Norbert Hartl <norbert(a)hartl.name> >>>>>>> wrote: >>>>>>> >>>>>>>> As I cannot work with the pharo VM right now >>>>>>> >>>>>>> what is the problem? >>>>>> >>>>>> I get the DNU SmallInteger>>add: all the time especially when using >>>>>> metacello (Using Versionner I get it nearly every attempt to validate the >>>>>> configuration). This occurred already a few times on the list. >>>>>> >>>>>> >>>>>>> >>>>>>>> I'm back to use Eliots Cog. But If I open a more recent image it >>>>>>>> complains about my vm being to old. What does it really check in order to >>>>>>>> complain? Some just version string/number parsing? Is it always sever? >>>>>>>> >>>>>>>> Norbert >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "Quality cannot be an afterthought." >>>>> >>>>> >>>> >>>> >>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >>> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" > > > > -- > Best regards, > Igor Stasenko. > -- www.tudorgirba.com "The coherence of a trip is given by the clearness of the goal."

July 25, 2013

Re: [Pharo-users] How are you doing your jenkins build scripts?

by Tudor Girba

Hi Norbert, In Moose, the configuration also contains a little package that comes with development tools. Among these development tools we have a couple of Moose-specific command lines. You can see a description here: http://www.tudorgirba.com/blog/moose-4-8-on-jenkins Cheers, Doru On Jul 25, 2013, at 5:10 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > Cami, > > thanks for the snippet. The commandline handler for tests is a super replacement for one part of my snippet. But how do you do the lint tests? > > Norbert > > Am 25.07.2013 um 16:54 schrieb Camillo Bruni <camillobruni(a)gmail.com>: > >> You use the built-in command line tools and no longer .st files. >> >> Pointers: >> ========= >> curl get.pharo.org | bash >> ./pharo Pharo.image --help >> ./pharo Pharo.image --list >> ./pharo Pharo.image test --help >> # everything should be pretty self explaining >> >> >> A typical script looks like this on jenkins: >> ========================================================================== >> wget --quiet -O - get.pharo.org/20+vm | bash >> >> ./pharo Pharo.image save $JOB_NAME --delete-old >> ./pharo $JOB_NAME.image --version > version.txt >> >> REPO=http://www.squeaksource.com/MetacelloRepository >> ./pharo $JOB_NAME.image config $REPO ConfigurationOf$JOB_NAME --install=$VERSION --groups='All OS',Tests >> ./pharo $JOB_NAME.image test --junit-xml-output "$JOB_NAME.*" >> >> zip -r $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes >> ========================================================================== >> >> >> On 2013-07-25, at 16:36, Norbert Hartl <norbert(a)hartl.name> wrote: >> >>> I'm close to having ported all of our projects to pharo 2.0. Now I'm asking myself what would be a proper setup to run my jenkins build scripts. With RPackage there are more packages in the system then before and in the jenkins scripts you need to invoke >>> >>> HDTestReport forPackages: #( â¦) >>> >>> In 1.4 I just added them manually. Using 2.0 makes this too cumbersome to deal with. So I need to figure out the amount of tests programmatically. The first I came up with (and that would solve my common use case) is something like >>> >>> >>> myPrefix := 'Emcee-' >>> myPackages := RPackage organizer packages select: [:each| each name beginsWith: myPrefix ]. >>> packagesWithTests := myPackages select: [ :package| package classes anySatisfy: [ :cls| cls includesBehavior: TestCase ] ]. >>> packagesNamedTest := myPackages select: [ :each| each name includesSubstring: '-Tests-' ]. >>> testPackages := packagesWithTests union: packagesNamedTest. >>> packages := myPackages difference: packagesNamedTest. >>> >>> HDTestReport runPackages: (testPackages collect: #name). >>> HDLintReport runPackages: (packages collect: #name) >>> >>> So I like to ask how you guys are doing it. Thanks in advance for your answers. >>> >>> Norbert >> >> > > -- www.tudorgirba.com "We can create beautiful models in a vacuum. But, to get them effective we have to deal with the inconvenience of reality."

July 25, 2013

Re: [Pharo-users] Your vm is too oldâ¦.

by Tudor Girba

I meant stable, but given that I thought Norbert needs to update his local copy, I said "latest stable". Confusing :) Doru On Jul 25, 2013, at 2:00 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Something I do not understand: "Latest stable" means latest or stable ? :). More specifically, How did you download it? > > Because as far as I knew it was not fixed by Esteban in the VM... But maybe one of the latest merges with Eliot's branch fixed it... > > > On Thu, Jul 25, 2013 at 1:55 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 25 July 2013 12:05, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > The workaround at the image level was needed only until we got the VM > > working. The details about the workaround are here: > > https://pharo.fogbugz.com/f/cases/10395/ > > > > I was sure that in the meantime, the problem was solved in the VM as well, > > but I cannot trace that information. Perhaps it is not. Esteban? > > > > Last time i discussed with Esteban about it, he said that he don't > knows where the problem in VM, > neither me. > > > > Cheers, > > Doru > > > > > > On Thu, Jul 25, 2013 at 9:13 AM, StÃ©phane Ducasse > > <stephane.ducasse(a)inria.fr> wrote: > >> > >> > >> On Jul 25, 2013, at 9:08 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> > >> This was a problem that we also had (when working in Moose), and Esteban > >> fixed it (first the workaround in the image, and then in the VM). We are > >> using this VM since some months now and the problem did not resurface. > >> > >> That is why I know it is fixed in the latest stable PharoVM. > >> > >> > >> Ok what igor is probably meaning is that we would prefer to get the system > >> running without having to have a workaround at the image level. > >> > >> > >> Cheers, > >> Doru > >> > >> > >> On Thu, Jul 25, 2013 at 9:03 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > >>> > >>> Doru, > >>> > >>> I'm sorry but I was mistaken somehow. I tried always to use the newest > >>> VM. I just downloaded a new vm a few minutes ago and now I cannot reproduce > >>> the problem anymore. That doesn't mean it won't appear anymore but I'll work > >>> with the pharo vm and see if it comes back. > >>> > >>> thanks, > >>> > >>> Norbert > >>> > >>> Am 24.07.2013 um 22:46 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > >>> > >>> > Use the latest stable VM. It should solve the problem. > >>> > > >>> > Doru > >>> > > >>> > > >>> > On Jul 24, 2013, at 10:34 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > >>> > > >>> >> > >>> >> > >>> >> Am 24.07.2013 um 18:21 schrieb StÃ©phane Ducasse > >>> >> <stephane.ducasse(a)inria.fr>: > >>> >> > >>> >>> > >>> >>> On Jul 24, 2013, at 5:13 PM, Norbert Hartl <norbert(a)hartl.name> > >>> >>> wrote: > >>> >>> > >>> >>>> As I cannot work with the pharo VM right now > >>> >>> > >>> >>> what is the problem? > >>> >> > >>> >> I get the DNU SmallInteger>>add: all the time especially when using > >>> >> metacello (Using Versionner I get it nearly every attempt to validate the > >>> >> configuration). This occurred already a few times on the list. > >>> >> > >>> >> > >>> >>> > >>> >>>> I'm back to use Eliots Cog. But If I open a more recent image it > >>> >>>> complains about my vm being to old. What does it really check in order to > >>> >>>> complain? Some just version string/number parsing? Is it always sever? > >>> >>>> > >>> >>>> Norbert > >>> >>> > >>> >>> > >>> >> > >>> > > >>> > -- > >>> > www.tudorgirba.com > >>> > > >>> > "Quality cannot be an afterthought." > >>> > > >>> > > >>> > >>> > >> > >> > >> > >> -- > >> www.tudorgirba.com > >> > >> "Every thing has its own flow" > >> > >> > > > > > > > > -- > > www.tudorgirba.com > > > > "Every thing has its own flow" > > > > -- > Best regards, > Igor Stasenko. > > -- www.tudorgirba.com "Things happen when they happen, not when you talk about them happening."

July 25, 2013

Re: [Pharo-users] How are you doing your jenkins build scripts?

by ClÃ©ment Bera

2013/7/25 Camillo Bruni <camillobruni(a)gmail.com> > > On 2013-07-25, at 17:10, Norbert Hartl <norbert(a)hartl.name> wrote: > > > Cami, > > > > thanks for the snippet. The commandline handler for tests is a super > replacement for one part of my snippet. But how do you do the lint tests? > > ah sorry, didn't see that last line. I didn't add support for that, so I > guess you're stuck with the script, > > ======================================================================= > ./pharo Pharo.image eval " > ... > your code goes here > ... > " > ======================================================================= > > We have a hacked version that works from the commandline for the lint > rules in 3.0 (might still work for 2.0): > > ======================================================================= > REPO="http://smalltalkhub.com/mc/ClementBera/code-critic-jenkins/main" > ./pharo Pharo.image config $REPO ConfigurationOfCommandLineMaintenanceTool > --install=stable > > # Run lint rules > ./pharo Pharo.image analyse2 >> maintenancePharo2.xml > ======================================================================= > This tool is a prototype huhum. You can have a look at: https://ci.inria.fr/pharo/job/Pharo-3.0-CodeCritics/ The script is: # install the code critics command line tool REPO="http://smalltalkhub.com/mc/ClementBera/code-critic-jenkins/main" ./pharo Pharo.image config $REPO ConfigurationOfCommandLineMaintenanceTool --install=stable # Run the analysis ./pharo Pharo.image analyse >> maintenancePharo.xml ./pharo Pharo.image analyse --packages='Kernel*' >> maintenanceKernel.xml ./pharo Pharo.image analyse2 >> maintenancePharo2.xml It uses both the CodeCritics and HDLintReport Of course now Pharo analysis on this build are not run with Manifest so there is a massive number of false positive. > > but I had the impression that there are too many false positives with the > selected rules. To collect the packages you can have a look at the > CommandLineHandler subclasses (I don't remember the name for the test > runner thingy anymore in 2.0). > > > > Am 25.07.2013 um 16:54 schrieb Camillo Bruni <camillobruni(a)gmail.com>: > > > >> You use the built-in command line tools and no longer .st files. > >> > >> Pointers: > >> ========= > >> curl get.pharo.org | bash > >> ./pharo Pharo.image --help > >> ./pharo Pharo.image --list > >> ./pharo Pharo.image test --help > >> # everything should be pretty self explaining > >> > >> > >> A typical script looks like this on jenkins: > >> > ========================================================================== > >> wget --quiet -O - get.pharo.org/20+vm | bash > >> > >> ./pharo Pharo.image save $JOB_NAME --delete-old > >> ./pharo $JOB_NAME.image --version > version.txt > >> > >> REPO=http://www.squeaksource.com/MetacelloRepository > >> ./pharo $JOB_NAME.image config $REPO ConfigurationOf$JOB_NAME > --install=$VERSION --groups='All OS',Tests > >> ./pharo $JOB_NAME.image test --junit-xml-output "$JOB_NAME.*" > >> > >> zip -r $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes > >> > ========================================================================== > >> > >> > >> On 2013-07-25, at 16:36, Norbert Hartl <norbert(a)hartl.name> wrote: > >> > >>> I'm close to having ported all of our projects to pharo 2.0. Now I'm > asking myself what would be a proper setup to run my jenkins build scripts. > With RPackage there are more packages in the system then before and in the > jenkins scripts you need to invoke > >>> > >>> HDTestReport forPackages: #( â¦) > >>> > >>> In 1.4 I just added them manually. Using 2.0 makes this too cumbersome > to deal with. So I need to figure out the amount of tests programmatically. > The first I came up with (and that would solve my common use case) is > something like > >>> > >>> > >>> myPrefix := 'Emcee-' > >>> myPackages := RPackage organizer packages select: [:each| each name > beginsWith: myPrefix ]. > >>> packagesWithTests := myPackages select: [ :package| package classes > anySatisfy: [ :cls| cls includesBehavior: TestCase ] ]. > >>> packagesNamedTest := myPackages select: [ :each| each name > includesSubstring: '-Tests-' ]. > >>> testPackages := packagesWithTests union: packagesNamedTest. > >>> packages := myPackages difference: packagesNamedTest. > >>> > >>> HDTestReport runPackages: (testPackages collect: #name). > >>> HDLintReport runPackages: (packages collect: #name) > >>> > >>> So I like to ask how you guys are doing it. Thanks in advance for your > answers. > >>> > >>> Norbert > >> > >> > > > > > > >

July 25, 2013

Re: [Pharo-users] How are you doing your jenkins build scripts?

by Camillo Bruni

On 2013-07-25, at 17:10, Norbert Hartl <norbert(a)hartl.name> wrote: > Cami, > > thanks for the snippet. The commandline handler for tests is a super replacement for one part of my snippet. But how do you do the lint tests? ah sorry, didn't see that last line. I didn't add support for that, so I guess you're stuck with the script, ======================================================================= ./pharo Pharo.image eval " ... your code goes here ... " ======================================================================= We have a hacked version that works from the commandline for the lint rules in 3.0 (might still work for 2.0): ======================================================================= REPO="http://smalltalkhub.com/mc/ClementBera/code-critic-jenkins/main" ./pharo Pharo.image config $REPO ConfigurationOfCommandLineMaintenanceTool --install=stable # Run lint rules ./pharo Pharo.image analyse2 >> maintenancePharo2.xml ======================================================================= but I had the impression that there are too many false positives with the selected rules. To collect the packages you can have a look at the CommandLineHandler subclasses (I don't remember the name for the test runner thingy anymore in 2.0). > Am 25.07.2013 um 16:54 schrieb Camillo Bruni <camillobruni(a)gmail.com>: > >> You use the built-in command line tools and no longer .st files. >> >> Pointers: >> ========= >> curl get.pharo.org | bash >> ./pharo Pharo.image --help >> ./pharo Pharo.image --list >> ./pharo Pharo.image test --help >> # everything should be pretty self explaining >> >> >> A typical script looks like this on jenkins: >> ========================================================================== >> wget --quiet -O - get.pharo.org/20+vm | bash >> >> ./pharo Pharo.image save $JOB_NAME --delete-old >> ./pharo $JOB_NAME.image --version > version.txt >> >> REPO=http://www.squeaksource.com/MetacelloRepository >> ./pharo $JOB_NAME.image config $REPO ConfigurationOf$JOB_NAME --install=$VERSION --groups='All OS',Tests >> ./pharo $JOB_NAME.image test --junit-xml-output "$JOB_NAME.*" >> >> zip -r $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes >> ========================================================================== >> >> >> On 2013-07-25, at 16:36, Norbert Hartl <norbert(a)hartl.name> wrote: >> >>> I'm close to having ported all of our projects to pharo 2.0. Now I'm asking myself what would be a proper setup to run my jenkins build scripts. With RPackage there are more packages in the system then before and in the jenkins scripts you need to invoke >>> >>> HDTestReport forPackages: #( â¦) >>> >>> In 1.4 I just added them manually. Using 2.0 makes this too cumbersome to deal with. So I need to figure out the amount of tests programmatically. The first I came up with (and that would solve my common use case) is something like >>> >>> >>> myPrefix := 'Emcee-' >>> myPackages := RPackage organizer packages select: [:each| each name beginsWith: myPrefix ]. >>> packagesWithTests := myPackages select: [ :package| package classes anySatisfy: [ :cls| cls includesBehavior: TestCase ] ]. >>> packagesNamedTest := myPackages select: [ :each| each name includesSubstring: '-Tests-' ]. >>> testPackages := packagesWithTests union: packagesNamedTest. >>> packages := myPackages difference: packagesNamedTest. >>> >>> HDTestReport runPackages: (testPackages collect: #name). >>> HDLintReport runPackages: (packages collect: #name) >>> >>> So I like to ask how you guys are doing it. Thanks in advance for your answers. >>> >>> Norbert >> >> > >

July 25, 2013

Re: [Pharo-users] How are you doing your jenkins build scripts?

by Norbert Hartl

Cami, thanks for the snippet. The commandline handler for tests is a super replacement for one part of my snippet. But how do you do the lint tests? Norbert Am 25.07.2013 um 16:54 schrieb Camillo Bruni <camillobruni(a)gmail.com>: > You use the built-in command line tools and no longer .st files. > > Pointers: > ========= > curl get.pharo.org | bash > ./pharo Pharo.image --help > ./pharo Pharo.image --list > ./pharo Pharo.image test --help > # everything should be pretty self explaining > > > A typical script looks like this on jenkins: > ========================================================================== > wget --quiet -O - get.pharo.org/20+vm | bash > > ./pharo Pharo.image save $JOB_NAME --delete-old > ./pharo $JOB_NAME.image --version > version.txt > > REPO=http://www.squeaksource.com/MetacelloRepository > ./pharo $JOB_NAME.image config $REPO ConfigurationOf$JOB_NAME --install=$VERSION --groups='All OS',Tests > ./pharo $JOB_NAME.image test --junit-xml-output "$JOB_NAME.*" > > zip -r $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes > ========================================================================== > > > On 2013-07-25, at 16:36, Norbert Hartl <norbert(a)hartl.name> wrote: > >> I'm close to having ported all of our projects to pharo 2.0. Now I'm asking myself what would be a proper setup to run my jenkins build scripts. With RPackage there are more packages in the system then before and in the jenkins scripts you need to invoke >> >> HDTestReport forPackages: #( â¦) >> >> In 1.4 I just added them manually. Using 2.0 makes this too cumbersome to deal with. So I need to figure out the amount of tests programmatically. The first I came up with (and that would solve my common use case) is something like >> >> >> myPrefix := 'Emcee-' >> myPackages := RPackage organizer packages select: [:each| each name beginsWith: myPrefix ]. >> packagesWithTests := myPackages select: [ :package| package classes anySatisfy: [ :cls| cls includesBehavior: TestCase ] ]. >> packagesNamedTest := myPackages select: [ :each| each name includesSubstring: '-Tests-' ]. >> testPackages := packagesWithTests union: packagesNamedTest. >> packages := myPackages difference: packagesNamedTest. >> >> HDTestReport runPackages: (testPackages collect: #name). >> HDLintReport runPackages: (packages collect: #name) >> >> So I like to ask how you guys are doing it. Thanks in advance for your answers. >> >> Norbert > >

July 25, 2013

Re: [Pharo-users] How are you doing your jenkins build scripts?

by Camillo Bruni

You use the built-in command line tools and no longer .st files. Pointers: ========= curl get.pharo.org | bash ./pharo Pharo.image --help ./pharo Pharo.image --list ./pharo Pharo.image test --help # everything should be pretty self explaining A typical script looks like this on jenkins: ========================================================================== wget --quiet -O - get.pharo.org/20+vm | bash ./pharo Pharo.image save $JOB_NAME --delete-old ./pharo $JOB_NAME.image --version > version.txt REPO=http://www.squeaksource.com/MetacelloRepository ./pharo $JOB_NAME.image config $REPO ConfigurationOf$JOB_NAME --install=$VERSION --groups='All OS',Tests ./pharo $JOB_NAME.image test --junit-xml-output "$JOB_NAME.*" zip -r $JOB_NAME.zip $JOB_NAME.image $JOB_NAME.changes ========================================================================== On 2013-07-25, at 16:36, Norbert Hartl <norbert(a)hartl.name> wrote: > I'm close to having ported all of our projects to pharo 2.0. Now I'm asking myself what would be a proper setup to run my jenkins build scripts. With RPackage there are more packages in the system then before and in the jenkins scripts you need to invoke > > HDTestReport forPackages: #( â¦) > > In 1.4 I just added them manually. Using 2.0 makes this too cumbersome to deal with. So I need to figure out the amount of tests programmatically. The first I came up with (and that would solve my common use case) is something like > > > myPrefix := 'Emcee-' > myPackages := RPackage organizer packages select: [:each| each name beginsWith: myPrefix ]. > packagesWithTests := myPackages select: [ :package| package classes anySatisfy: [ :cls| cls includesBehavior: TestCase ] ]. > packagesNamedTest := myPackages select: [ :each| each name includesSubstring: '-Tests-' ]. > testPackages := packagesWithTests union: packagesNamedTest. > packages := myPackages difference: packagesNamedTest. > > HDTestReport runPackages: (testPackages collect: #name). > HDLintReport runPackages: (packages collect: #name) > > So I like to ask how you guys are doing it. Thanks in advance for your answers. > > Norbert

July 25, 2013

How are you doing your jenkins build scripts?

by Norbert Hartl

I'm close to having ported all of our projects to pharo 2.0. Now I'm asking myself what would be a proper setup to run my jenkins build scripts. With RPackage there are more packages in the system then before and in the jenkins scripts you need to invoke HDTestReport forPackages: #( â¦) In 1.4 I just added them manually. Using 2.0 makes this too cumbersome to deal with. So I need to figure out the amount of tests programmatically. The first I came up with (and that would solve my common use case) is something like myPrefix := 'Emcee-' myPackages := RPackage organizer packages select: [:each| each name beginsWith: myPrefix ]. packagesWithTests := myPackages select: [ :package| package classes anySatisfy: [ :cls| cls includesBehavior: TestCase ] ]. packagesNamedTest := myPackages select: [ :each| each name includesSubstring: '-Tests-' ]. testPackages := packagesWithTests union: packagesNamedTest. packages := myPackages difference: packagesNamedTest. HDTestReport runPackages: (testPackages collect: #name). HDLintReport runPackages: (packages collect: #name) So I like to ask how you guys are doing it. Thanks in advance for your answers. Norbert

July 25, 2013