Re: Draft release notes complete

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Draft release notes complete
Date: 2012-09-07 16:50:44
Message-ID: 504A25E4.90206@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 09/07/2012 09:57 AM, Magnus Hagander wrote:
> On Thu, Sep 6, 2012 at 1:06 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>>
>> A complete run of this process takes less than 15 minutes. And as I have
>> pointed out elsewhere that could be reduced substantially by skipping
>> certain steps. It's as simple as changing the command line in the crontab
>> entry.
> Is it possible to run it only when the *docs* have changed, and not
> when it's just a code-commit? meaning, is the detection smart enough
> for that?
>
>

There is a filter mechanism used in detecting is a run is needed, and in
modern versions of the client (Release 4.7, one version later than
guaibasaurus is currently using) it lets you have both include and
exclude filters. For example, you could have this config setting:

trigger_include => qr(/doc/src/),

and it would then only match changed files in the docs tree.

It's a global mechanism, not per step. So it will run all the steps
(other than those you have told it to skip) if it finds any files
changed that match the filter conditions.

If you do that you would probably want to have two animals, one doing
docs builds only and running frequently, one doing the dist stuff much
less frequently.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-09-07 17:49:08 Re: Proof of concept: standalone backend with full FE/BE protocol
Previous Message Amit Kapila 2012-09-07 14:53:57 Re: Issue observed in cascade standby setup and analysis for same