Re: cirrus-ci cross-build interactions? - Mailing list pgsql-hackers

From James Coleman
Subject Re: cirrus-ci cross-build interactions?
Date
Msg-id CAAaqYe-wWcZ1gG8Y2A7EApveHCLY_uvA98e_b+b8hk-LuCOKjA@mail.gmail.com
Whole thread Raw
In response to Re: cirrus-ci cross-build interactions?  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Mon, Sep 26, 2022 at 10:48 PM Andres Freund <andres@anarazel.de> wrote:
>
> Hi,
>
> On 2022-09-26 22:36:24 -0400, James Coleman wrote:
> > I had a build on Cirrus CI fail tonight in what I have to assume was
> > either a problem with caching across builds or some such similar
> > flakiness. In the Debian task [1] I received this error:
> >
> > su postgres -c "make -s -j${BUILD_JOBS} world-bin"
> > In file included from parser.c:25:
> > ./gramparse.h:29:10: fatal error: 'gram.h' file not found
> > #include "gram.h"
> > ^~~~~~~~
> > 1 error generated.
> > make[3]: *** [../../../src/Makefile.global:1078: parser.bc] Error 1
> > make[3]: *** Waiting for unfinished jobs....
> > make[2]: *** [common.mk:36: parser-recursive] Error 2
> > make[1]: *** [Makefile:42: all-backend-recurse] Error 2
> > make: *** [GNUmakefile:21: world-bin-src-recurse] Error 2
> >
> > There were no changes in the commits I'd made to either parser.c or
> > gramparse.h or gram.h. After running "git commit --amend --no-edit"
> > (with zero changes) to rewrite the commit and forcing pushing the
> > build [2] seems to be fine. I've double-checked there are no
> > differences between the commits on the two builds (git diff shows no
> > output).
> >
> > Is it possible we're missing some kind of necessary build isolation in
> > the Cirrus CI scripting?
>
> Very unlikely - most of the tasks, including debian, use VMs that are thrown
> away after a single use.
>
> The explanation is likely that you're missing
>
> commit 16492df70bb25bc99ca3c340a75ba84ca64171b8
> Author: John Naylor <john.naylor@postgresql.org>
> Date:   2022-09-15 10:24:55 +0700
>
>     Blind attempt to fix LLVM dependency in the backend
>
> and that the reason you noticed this in one build but not another is purely
> due to scheduling variances.

Yes, as noted in my child reply to yours the egg is on my face -- I
hadn't rebased on the latest commits for a little too long.

Thanks for the troubleshooting and relevant fix.

James Coleman



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Adding a clang-format file
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Add LSN along with offset to error messages reported for WAL file read/write/validate header failures