Thread: cirrus-ci cross-build interactions?
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?
Thanks,
James Coleman
1: https://cirrus-ci.com/task/6141559258218496
2: https://cirrus-ci.com/build/6309235720978432
On Mon, Sep 26, 2022 at 10:36 PM James Coleman <jtc331@gmail.com> 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?
>
> Thanks,
> James Coleman
>
> 1: https://cirrus-ci.com/task/6141559258218496
> 2: https://cirrus-ci.com/build/6309235720978432
Hmm, it looks like I don't have the commit that came out of this
thread [1] about gram.h issues; perhaps that's the issue.
I'm not sure why it fails sometimes and not others, however, though I
noticed that on the second build from my original email the Debian
step passed while the compiler warnings step failed with the same
error.
James Coleman
1: https://www.postgresql.org/message-id/20220914210427.y26tkagmxo5wwbvp%40awork3.anarazel.de
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.
Greetings,
Andres Freund
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