Pillar for 30 gone the way of the dodo on the CI
Hello, It may have been a long time without it but still... I ran the doc job on my CI and got this that wasn't working: https://ci.inria.fr/pharo-contribution/job/Pillar/PHARO=30,VERSION=stable,VM... Hum, yes, but ... why remove the doc tools as this is quite an important thing to keep around for all Pharo versions? I'll go to 4.0 but there are other dependencies etc for the OS maybe etc. Not good as I need to migrate these things for my customer as well. Phil
Le 30/09/2015 18:38, phil@highoctane.be a écrit :
Hello,
It may have been a long time without it but still...
I ran the doc job on my CI and got this that wasn't working:
https://ci.inria.fr/pharo-contribution/job/Pillar/PHARO=30,VERSION=stable,VM...
Hum, yes, but ... why remove the doc tools as this is quite an important thing to keep around for all Pharo versions?
I'll go to 4.0 but there are other dependencies etc for the OS maybe etc. Not good as I need to migrate these things for my customer as well.
Phil
Hi Phil, We removed the Pillar job for Pharo 3 because we introduced an new feature not backward compatible. So we freezed the Pillar version for Pharo 3. So we do not need a job for it anymore since it will not change and we do not want to keep a red job for "Pillar - Pharo 3 - Development". You can still load the stable version of Pillar in Pharo 3, but this version will not evolve anymore. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France
Ok, where? Phil On Wed, Sep 30, 2015 at 7:57 PM, Ferlicot D. Cyril <cyril.ferlicot@gmail.com
wrote:
Le 30/09/2015 18:38, phil@highoctane.be a écrit :
Hello,
It may have been a long time without it but still...
I ran the doc job on my CI and got this that wasn't working:
https://ci.inria.fr/pharo-contribution/job/Pillar/PHARO=30,VERSION=stable,VM...
Hum, yes, but ... why remove the doc tools as this is quite an important thing to keep around for all Pharo versions?
I'll go to 4.0 but there are other dependencies etc for the OS maybe etc. Not good as I need to migrate these things for my customer as well.
Phil
Hi Phil,
We removed the Pillar job for Pharo 3 because we introduced an new feature not backward compatible. So we freezed the Pillar version for Pharo 3. So we do not need a job for it anymore since it will not change and we do not want to keep a red job for "Pillar - Pharo 3 - Development".
You can still load the stable version of Pillar in Pharo 3, but this version will not evolve anymore.
-- Cyril Ferlicot
165 Avenue Bretagne Lille 59000 France
phil@highoctane.be <phil@highoctane.be> writes:
Ok, where?
in Pharo 3, open the Catalog Browser, choose Pillar, and click "Install Stable Version". You will get 2 warnings you can safely ignore. You can run the unit tests to check everything works fine (Pillar contains 2198 unit tests, in this version, covering 92% of the source code). -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
Downloaded the book-skeleton, patched the download script so that it gets the centos things right and the Pharo4VM. Now, changes in Pillar made my books unsuable, namely the introduction of things like this: ${tag:parameter=value|parameter2=value2}$ made contents with bash shell scripts unparsable. Yeah, but there are often such things. Like in: Il existe une autre variable ==${ACQSYS_RRDPRINT_TIMEFRAME_SHORT}== qui couvre une période plus courte How do I solve that with the new markup? Phil On Wed, Sep 30, 2015 at 7:57 PM, Ferlicot D. Cyril <cyril.ferlicot@gmail.com> wrote:
Le 30/09/2015 18:38, phil@highoctane.be a écrit :
Hello,
It may have been a long time without it but still...
I ran the doc job on my CI and got this that wasn't working:
https://ci.inria.fr/pharo-contribution/job/Pillar/PHARO=30,VERSION=stable,VM...
Hum, yes, but ... why remove the doc tools as this is quite an important thing to keep around for all Pharo versions?
I'll go to 4.0 but there are other dependencies etc for the OS maybe
etc.
Not good as I need to migrate these things for my customer as well.
Phil
Hi Phil,
We removed the Pillar job for Pharo 3 because we introduced an new feature not backward compatible. So we freezed the Pillar version for Pharo 3. So we do not need a job for it anymore since it will not change and we do not want to keep a red job for "Pillar - Pharo 3 - Development".
You can still load the stable version of Pillar in Pharo 3, but this version will not evolve anymore.
-- Cyril Ferlicot
165 Avenue Bretagne Lille 59000 France
Le 30/09/2015 22:32, phil@highoctane.be a écrit :
Downloaded the book-skeleton, patched the download script so that it gets the centos things right and the Pharo4VM.
Now, changes in Pillar made my books unsuable, namely the introduction of things like this:
${tag:parameter=value|parameter2=value2}$
made contents with bash shell scripts unparsable.
Yeah, but there are often such things.
Like in:
Il existe une autre variable ==${ACQSYS_RRDPRINT_TIMEFRAME_SHORT}== qui couvre une période plus courte
How do I solve that with the new markup?
Phil
You can just escape like this: Il existe une autre variable ==\${ACQSYS_RRDPRINT_TIMEFRAME_SHORT}== qui couvre une période plus courte :) -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France
Which is a pain as when I copy/paste a shell script full of those, I won't do that. Is this also doing the same thing in blocks like: [[[label=.bashrc|caption=Ajouts à .bashrc|language=bash ${SOMEVAR:-} ]]] I am not gonna escape those things as what happens is copy/pasting code. That there are no such directives in Markdiwn is what makes it nice to use and hassle free. I would escape your directives and leave the core of the text alone. Well, what do you think? Phil On Wed, Sep 30, 2015 at 10:38 PM, Ferlicot D. Cyril < cyril.ferlicot@gmail.com> wrote:
Le 30/09/2015 22:32, phil@highoctane.be a écrit :
Downloaded the book-skeleton, patched the download script so that it gets the centos things right and the Pharo4VM.
Now, changes in Pillar made my books unsuable, namely the introduction of things like this:
${tag:parameter=value|parameter2=value2}$
made contents with bash shell scripts unparsable.
Yeah, but there are often such things.
Like in:
Il existe une autre variable ==${ACQSYS_RRDPRINT_TIMEFRAME_SHORT}== qui couvre une période plus courte
How do I solve that with the new markup?
Phil
You can just escape like this:
Il existe une autre variable ==\${ACQSYS_RRDPRINT_TIMEFRAME_SHORT}== qui couvre une période plus courte
:)
-- Cyril Ferlicot
165 Avenue Bretagne Lille 59000 France
phil@highoctane.be <phil@highoctane.be> writes:
Which is a pain as when I copy/paste a shell script full of those, I won't do that.
I agree that's a pain. But you have to do it.
Is this also doing the same thing in blocks like:
[[[label=.bashrc|caption=Ajouts à .bashrc|language=bash
${SOMEVAR:-}
]]]
text between [[[ and ]]] is used verbatim and thus not parsed by Pillar. You can safely use Pillar-protected characters in there and they won't be interpreted.
I am not gonna escape those things as what happens is copy/pasting code. That there are no such directives in Markdiwn is what makes it nice to use and hassle free.
this is also what makes Markdown less powerful. We had to find a compromise. I think the ${tag}$ is a good one because it is pluggable. We can use it for many things: file inclusion, table of content declaration, bibliography citations, any plugin you can think of.
I would escape your directives and leave the core of the text alone.
I didn't get that. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
phil@highoctane.be <phil@highoctane.be> writes:
Downloaded the book-skeleton, patched the download script so that it gets the centos things right and the Pharo4VM.
Now, changes in Pillar made my books unsuable, namely the introduction of things like this:
${tag:parameter=value|parameter2=value2}$
made contents with bash shell scripts unparsable.
indeed, sorry about that. This new syntax breaks existing documents. Nevertheless, this new syntax has been created exactly for the purpose of limiting future problems: new syntax will not be necessary most of the time because ${tag}$ is pluggable. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
On 01-10-15 09:41, Stephan Eggermont wrote:
On 30-09-15 19:57, Ferlicot D. Cyril wrote:
We removed the Pillar job for Pharo 3 because we introduced an new feature not backward compatible.
Why is that a reason to remove the build? You have a configuration, don't you?
I would suggest: move to a separate job that is run much less often and doesn't keep so many old artifacts. That makes it easier to get old stuff running again. Stephan
In Jenkins you specify configuration matrix (versions of pharo versus type (development, stable, ...)).. So it will run development for all versions, even pharo 30 (which is now permanently broken) -----Original Message----- From: "Stephan Eggermont" <stephan@stack.nl> Sent: â10/â1/â2015 9:47 AM To: "pharo-users@lists.pharo.org" <pharo-users@lists.pharo.org> Subject: Re: [Pharo-users] Pillar for 30 gone the way of the dodo on the CI On 01-10-15 09:41, Stephan Eggermont wrote:
On 30-09-15 19:57, Ferlicot D. Cyril wrote:
We removed the Pillar job for Pharo 3 because we introduced an new feature not backward compatible.
Why is that a reason to remove the build? You have a configuration, don't you?
I would suggest: move to a separate job that is run much less often and doesn't keep so many old artifacts. That makes it easier to get old stuff running again. Stephan
Is CI an archive?
On 01 Oct 2015, at 10:05, Peter Uhnak <i.uhnak@gmail.com> wrote:
In Jenkins you specify configuration matrix (versions of pharo versus type (development, stable, ...)).. So it will run development for all versions, even pharo 30 (which is now permanently broken) From: Stephan Eggermont <mailto:stephan@stack.nl> Sent: â10/â1/â2015 9:47 AM To: pharo-users@lists.pharo.org <mailto:pharo-users@lists.pharo.org> Subject: Re: [Pharo-users] Pillar for 30 gone the way of the dodo on the CI
On 01-10-15 09:41, Stephan Eggermont wrote:
On 30-09-15 19:57, Ferlicot D. Cyril wrote:
We removed the Pillar job for Pharo 3 because we introduced an new feature not backward compatible.
Why is that a reason to remove the build? You have a configuration, don't you?
I would suggest: move to a separate job that is run much less often and doesn't keep so many old artifacts. That makes it easier to get old stuff running again.
Stephan
On 01 Oct 2015, at 10:07, Marcus Denker <marcus.denker@inria.fr> wrote:
Is CI an archive?
What I mean: it seems to me not possible to keep all CI build alive âforeverâ as a CI server build. Shouldnât we separate âarchival of buildsâ from âactive ciâ? For Pharo itself we do that, as we do not have the manpower (we just donât) to keep the CI alive for stable and dev, yet every build ever is on files.pharo.org <http://files.pharo.org/> *forever*, archived. Marcus
On 01 Oct 2015, at 10:05, Peter Uhnak <i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>> wrote:
In Jenkins you specify configuration matrix (versions of pharo versus type (development, stable, ...)).. So it will run development for all versions, even pharo 30 (which is now permanently broken) From: Stephan Eggermont <mailto:stephan@stack.nl> Sent: â10/â1/â2015 9:47 AM To: pharo-users@lists.pharo.org <mailto:pharo-users@lists.pharo.org> Subject: Re: [Pharo-users] Pillar for 30 gone the way of the dodo on the CI
On 01-10-15 09:41, Stephan Eggermont wrote:
On 30-09-15 19:57, Ferlicot D. Cyril wrote:
We removed the Pillar job for Pharo 3 because we introduced an new feature not backward compatible.
Why is that a reason to remove the build? You have a configuration, don't you?
I would suggest: move to a separate job that is run much less often and doesn't keep so many old artifacts. That makes it easier to get old stuff running again.
Stephan
So let us archive it but now my scripts are broken. Stef Le 1/10/15 10:10, Marcus Denker a écrit :
On 01 Oct 2015, at 10:07, Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
Is CI an archive?
What I mean: it seems to me not possible to keep all CI build alive âforeverâ as a CI server build. Shouldnât we separate âarchival of buildsâ from âactive ciâ?
For Pharo itself we do that, as we do not have the manpower (we just donât) to keep the CI alive for stable and dev, yet every build ever is on files.pharo.org <http://files.pharo.org> *forever*, archived.
Marcus
On 01 Oct 2015, at 10:05, Peter Uhnak <i.uhnak@gmail.com <mailto:i.uhnak@gmail.com>> wrote:
In Jenkins you specify configuration matrix (versions of pharo versus type (development, stable, ...)).. So it will run development for all versions, even pharo 30 (which is now permanently broken) ------------------------------------------------------------------------ From: Stephan Eggermont <mailto:stephan@stack.nl> Sent: â10/â1/â2015 9:47 AM To: pharo-users@lists.pharo.org <mailto:pharo-users@lists.pharo.org> Subject: Re: [Pharo-users] Pillar for 30 gone the way of the dodo on the CI
On 01-10-15 09:41, Stephan Eggermont wrote:
On 30-09-15 19:57, Ferlicot D. Cyril wrote:
We removed the Pillar job for Pharo 3 because we introduced an new feature not backward compatible.
Why is that a reason to remove the build? You have a configuration, don't you?
I would suggest: move to a separate job that is run much less often and doesn't keep so many old artifacts. That makes it easier to get old stuff running again.
Stephan
On 03-10-15 09:16, stepharo wrote:
So let us archive it but now my scripts are broken.
If we want the old scripts to continue working, instead of creating a new (old) job for it we would need some mechanism to tell the build matrix in more detail what should happen to which build: only build nightly/weekly, and keep just a few artifacts Stephan
On 01-10-15 10:05, Peter Uhnak wrote:
In Jenkins you specify configuration matrix (versions of pharo versus type (development, stable, ...)).. So it will run development for all versions, even pharo 30 (which is now permanently broken)
Shouldn't #'development' for Pharo3.x then point to #'stable'? There is no development, there could be bugfixes. The matrix indeed assumes that you want all combinations, while what we actually need for the build is something like the Matrix Combinations Plugin https://wiki.jenkins-ci.org/display/JENKINS/Matrix+Combinations+Plugin I haven't tested the plugin yet. Stephan
You can exclude some of the combinations from matrix. E.g. exclude build for 30 & development.
On 01 Oct 2015, at 14:04, Stephan Eggermont <stephan@stack.nl> wrote:
On 01-10-15 10:05, Peter Uhnak wrote:
In Jenkins you specify configuration matrix (versions of pharo versus type (development, stable, ...)).. So it will run development for all versions, even pharo 30 (which is now permanently broken)
Shouldn't #'development' for Pharo3.x then point to #'stable'? There is no development, there could be bugfixes.
The matrix indeed assumes that you want all combinations, while what we actually need for the build is something like the Matrix Combinations Plugin https://wiki.jenkins-ci.org/display/JENKINS/Matrix+Combinations+Plugin I haven't tested the plugin yet.
Stephan
Stephan Eggermont <stephan@stack.nl> writes:
On 01-10-15 10:05, Peter Uhnak wrote:
In Jenkins you specify configuration matrix (versions of pharo versus type (development, stable, ...)).. So it will run development for all versions, even pharo 30 (which is now permanently broken)
Shouldn't #'development' for Pharo3.x then point to #'stable'? There is no development, there could be bugfixes.
The matrix indeed assumes that you want all combinations, while what we actually need for the build is something like the Matrix Combinations Plugin https://wiki.jenkins-ci.org/display/JENKINS/Matrix+Combinations+Plugin I haven't tested the plugin yet.
I don't want the main Pillar job to be marked as having failed for a platform I don't want to maintain. Please create a new job as you proposed in another email. Nevertheless, I agree with Marcus that continuous integration should not be used as an image archive. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill
We removed the Pillar job for Pharo 3 because we introduced an new feature not backward compatible.
Why is that a reason to remove the build? You have a configuration, don't you?
I would suggest: move to a separate job that is run much less often and doesn't keep so many old artifacts. That makes it easier to get old stuff running again.
+ 10000
well⦠Iâm with Marcus here: the real problem is that we shouldnât use the CI as a repository for download images. Instead, I would keep them in a public file server (pretty much the same we do with Pharo, we do not keep all builds (or versions) in the CI, but all history is available at files.pharo.org. And we cannot keep this indefinitely because of many reasons (and the fact that INRIA servers are not infinite is one important). So, maybe we should make community available some files.pharo.org/contribution where jobs can upload the built versions (not the full history, but at least stable and development versions? that way people can still find their versions and we can reduce a bit the weight of pharo-contribution? cheers, Esteban
On 03 Oct 2015, at 09:15, stepharo <stepharo@free.fr> wrote:
We removed the Pillar job for Pharo 3 because we introduced an new feature not backward compatible.
Why is that a reason to remove the build? You have a configuration, don't you?
I would suggest: move to a separate job that is run much less often and doesn't keep so many old artifacts. That makes it easier to get old stuff running again.
+ 10000
> well⦠Iâm with Marcus here: the real problem is that we shouldnât use the CI as a repository for download images. Yes I understand but now I have to edit my scripts and find what it not working. > Instead, I would keep them in a public file server (pretty much the same we do with Pharo, we do not keep all builds (or versions) in the CI, but all history is available at files.pharo.org. > And we cannot keep this indefinitely because of many reasons (and the fact that INRIA servers are not infinite is one important). > > So, maybe we should make community available some files.pharo.org/contribution where jobs can upload the built versions (not the full history, but at least stable and development versions? would be nice. > that way people can still find their versions and we can reduce a bit the weight of pharo-contribution? > > cheers, > Esteban > >> On 03 Oct 2015, at 09:15, stepharo <stepharo@free.fr> wrote: >> >> >>>>> We removed the Pillar job for Pharo 3 because we introduced an new >>>>> feature not backward compatible. >>>> Why is that a reason to remove the build? You have a configuration, >>>> don't you? >>> I would suggest: move to a separate job that is run much less often >>> and doesn't keep so many old artifacts. That makes it easier to get old stuff running again. >> + 10000 >> >> >> > >
participants (9)
-
Damien Cassou -
Esteban Lorenzano -
Ferlicot D. Cyril -
Marcus Denker -
Peter Uhnak -
phil＠highoctane.be -
Stephan Eggermont -
stepharo -
Yuriy Tymchuk