Spurious Bazel failures when compiling the graphs back end

[fruffy]

Bazel has been failing recently with this error message:

 Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
In file included from external/com_github_p4lang_p4c/backends/graphs/parsers.h:22,
                 from external/com_github_p4lang_p4c/backends/graphs/parsers.cpp:18:
external/com_github_p4lang_p4c/backends/graphs/graphs.h:25:2: error: #error "This backend requires the boost graph headers, which could not be found"
   25 | #error "This backend requires the boost graph headers, which could not be found"

I tried to fix it with
https://github.com/p4lang/p4c/actions/runs/9257567840/job/25466961631?pr=4678 but that did not work it seems.
I am unsure how this failure can happen. @smolkaj any idea?

[ChrisDodd]

This seems to be intermittent, which indicates that there might be some difference depending on which specific CI machine it ends up running on. Does the bazel build attempt to first install all prereqs (like boost::graphs), or does it rely on some things being preinstalled somehow?

[fruffy]

This seems to be intermittent, which indicates that there might be some difference depending on which specific CI machine it ends up running on. Does the bazel build attempt to first install all prereqs (like boost::graphs), or does it rely on some things being preinstalled somehow?

The error in particular might actually be totally unrelated to the boost::graphs installation since they do not perform the same CMake check.
They convert the #cmakedefine in the config file to an actual #define
https://github.com/p4lang/p4c/blob/main/BUILD.bazel#L32
There must be something going wrong here.

[smolkaj]

Ugh, that's not great -- will need to take a look.

Is this actively blocking p4c PRs or are we disregarding this failures during submissions for the time being?

[fruffy]

Is this actively blocking p4c PRs or are we disregarding this failures during submissions for the time being?

We are disregarding the failures, but the spurious failures cause disruptions in the merge queue, which can be annoying (when the Bazel test fails the PR is dequeued and has to be manually resubmitted to the queue).

[ChrisDodd]

The failure rate seems to be only 10-30%, so it is not too bad -- when a merge fails, just resubmit and it will succeed (at least I've never had it fail the second time). Maybe a connection to test machine load? When there's a load spike, a bunch of things will fail which will reduce the load, so the resubmit tends to pass.

[smolkaj]

Trying to figure out who added that particular build rule so they can take a look.

[smolkaj]

I see it was added in #2849 by @maemre. Would you be able to take a look, Mehmet?

[smolkaj]

From Google's side, we're not currently using this backend, so we would be okay with commenting out the target for the time being.

[fruffy]

I will make the Bazel tests optional until we are able to fix the stability issues.

[smolkaj]

Can we instead just comment out the graph backend build rule, so we can prevent further regressions?

…

On Tue, Jun 11, 2024 at 10:18 Fabian Ruffy ***@***.***> wrote: I will make the Bazel tests optional until we are able to fix the stability issues. — Reply to this email directly, view it on GitHub <#4685 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABSVS4QFSMI64ICES5DCR4LZG4WPNAVCNFSM6AAAAABILSBS3GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNRRGI2TONZXG4> . You are receiving this because you were assigned.Message ID: ***@***.***>

[maemre]

I added this when doing debugging for the PR #2898 but that PR is not merged. I left Google before it could be merged and there hasn't been any activity on it in the past 3 years. If Google does not need it, there might not be other users for building the graphs backend using Bazel. So, I think commenting out/removing the graph backend build rule is fine.

[fruffy]

After #4720 this appears resolved.