Pillar for 30 gone the way of the dodo on the CI

Le 30/09/2015 18:38, [hidden email] a écrit : 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

Le 30/09/2015 22:32, [hidden email] a écrit : 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

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?

Stephan

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-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? 

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

[hidden email] <[hidden email]> writes:


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

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

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.

Stephan Eggermont <[hidden email]> writes:

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

So let us archive it but now my scripts are broken.

Stef

On 01 Oct 2015, at 10:07, Marcus Denker <[hidden email]> 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 *forever*, archived.

Marcus

On 01 Oct 2015, at 10:05, Peter Uhnak <[hidden email]> 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: [hidden email]
Sent: ‎10/‎1/‎2015 9:47 AM
To: [hidden email]
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