Re: Adding CI to our tree - Mailing list pgsql-hackers

From Justin Pryzby
Subject Re: Adding CI to our tree
Date
Msg-id 20220227031057.GD25269@telsasoft.com
Whole thread Raw
In response to Re: Adding CI to our tree  (Andres Freund <andres@anarazel.de>)
Responses Re: Adding CI to our tree  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Sat, Feb 26, 2022 at 06:50:00PM -0800, Andres Freund wrote:
> Hi,
> 
> On 2022-02-26 20:43:52 -0600, Justin Pryzby wrote:
> > This doesn't do the right thing - I just tried.
> > https://cirrus-ci.org/guide/writing-tasks/#environment-variables
> > | changesInclude function can be very useful for skipping some tasks when no changes to sources have been made
sincethe last successful Cirrus CI build.
 
> 
> > That means it will not normally rebuild docs (and then this still requires
> > resolving the "base branch").
> 
> Why would we want to rebuild docs if they're the same as in the last build for
> the same branch?  For cfbot purposes each commit is independent from the prior
> commit, so it should rebuild it every time if the CF entry has changes to the
> docs.

I did git commit --amend --no-edit and repushed to github to trigger a new CI
run, and it did this: https://github.com/justinpryzby/postgres/runs/5347878714

This is in a branch with changes to doc.  I wasn't intending it to skip
building docs on this branch just because the same, changed docs were
previously built.

Why wouldn't the docs be built following the same logic as the rest of the
sources ?  If someone renames or removes an xref target, shouldn't CI fail on
its next run for a patch which tries to reference it ?  It would fail on the
buildfarm, and I think one major use for the CI is to minimize the post-push
cleanup cycles.

Are you sure about cfbot ?  AIUI cirrus would see that docs didn't change
relative to the previous run for branch: commitfest/NN/MMMM.

-- 
Justin



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Adding CI to our tree
Next
From: Pavel Stehule
Date:
Subject: Re: [Proposal] Global temporary tables