[umaucher]

Follow-up to #246. The fetch step introduced there did not prevent the qnx.com timeout in the build step (https://github.com/eclipse-score/persistency/actions/runs/39727791292/attempts/1).

• bazel fetch only covers the loading phase. The QNX SDP (*_qcc_*_toolchain_pkg) is a toolchain repository resolved during analysis, so the fetch succeeded after about 9 seconds without downloading it.
• The build step then downloaded it during analysis and failed with Connect timed out, with no retry.
• The fetch step now runs bazel build --nobuild, which runs analysis, so the SDP download happens inside the retry loop.
• The comments that keep the fetch and build commands in sync, and the retry inputs, are unchanged.

[lurtz]

approved, but I am a bit confused. In inc_someip_gateway I use the Github Cache along with bazel fetch and there it downloads the QNX SDP.

[umaucher]

looks like a persistency specific topic ... some additional analysis:

The difference is --build_tests_only: persistency's rc sets it for test, and bazel fetch inherits test options. With it, bazel fetch //score/kvs … analyzes 0 targets ("Analyzed 0 targets (10 packages loaded)"), so toolchain resolution never runs and the SDP is not downloaded. Adding --nobuild_tests_only makes the fetch analyze and download it. In inc_someip_gateway no such flag is set, so bazel fetch analyzes the targets and pulls the SDP. bazel build --nobuild always runs analysis and ignores test: options, so it behaves the same in every repo.

so the --nobuild is still more reliable but maybe still specific

[umaucher]

see https://github.com/eclipse-score/persistency/blob/main/score.bazelrc/score_toolchain.bazelrc#L19