Doris-Breakwater commented on issue #70013: URL: https://github.com/apache/doris/issues/70013#issuecomment-6594777125
**Assessment:** This should be triaged to the maintainers of `Doris_Coverage_CheckCoverageFe` / `doris-teamcity-settings` as a CI bootstrap/download failure. The report does not establish an FE compilation, unit-test, or coverage regression caused by #69938. The internal-endpoint explanation is plausible, but the precise network failure still needs confirmation. **Evidence and scope** - The quoted command runs `wget → tar → PATH export → mvn --version → build.sh --fe` through `&&`. A failed download therefore prevents the later commands from executing. GNU Wget defines exit status `4` as a network failure; it does not identify whether DNS, routing, a proxy, or the connection failed. With `-q` and the abbreviated log, the failing subcommand and exact error should be captured explicitly. Neither three completed attempts nor a routing failure can be inferred solely from the roughly 20-second duration. See the [GNU Wget manual](https://www.gnu.org/software/wget/manual/wget.html#Exit-Status). - Alibaba Cloud lists `oss-cn-hongkong-internal.aliyuncs.com` as the Hong Kong internal endpoint and `oss-cn-hongkong.aliyuncs.com` as its public counterpart. Successful downloads from other buckets on the **host** do not establish connectivity to this bucket from the **container**. See [OSS endpoint documentation](https://www.alibabacloud.com/help/en/oss/user-guide/regions-and-endpoints). - During this investigation, an unauthenticated HEAD request to the proposed public Maven object returned HTTP 200, `application/gzip`, and a content length of 9,233,336 bytes. That supports testing this alternative; it does not verify a complete download, checksum, or reachability from the affected agent. - At local Doris snapshot `82646c38c0069eee4b1704eafef416f969bd4b93`, the analogous [performance bootstrap](https://github.com/apache/doris/blob/82646c38c0069eee4b1704eafef416f969bd4b93/regression-test/pipeline/performance/compile.sh#L78) installs Maven before invoking the build. The exact reported coverage bootstrap was not found in that snapshot, and the separate settings repository was unavailable locally. This snapshot is not asserted to be the failing build revision. The [maintainer response on #60918](https://github.com/apache/doris/issues/60918#issuecomment-3990326384) confirms a previous coverage-script repair was made in internal CI configuration; that JaCoCo-path failure is different from this download failure. [#67785](https://github.com/apache/doris/issues/67785) concerns rerun triggering, also a separate mechanism. **Information needed to confirm the cause** 1. The effective TeamCity script and settings revision for builds `1088718` and `1089151`, the Doris commit SHA, and the resolved container image digest. The `latest` tag alone is insufficient for reproduction. Direct access to the linked TeamCity log returned HTTP 401 here. 2. On an affected agent, repeat the Maven download inside the same image and Docker network configuration, removing `-q`, enabling `--server-response`, setting bounded DNS/connect/read timeouts, and recording the download's exit status separately. Capture hostname resolution and sanitized proxy/network configuration for both host and container. Compare the internal and public URLs for the **same object**. 3. A successful full public download and checksum verification in that container. If internal access works on the host but fails in the container, investigate Docker DNS, forwarding, and proxy propagation; if both fail internally while public access works, investigate the agent pool's intended internal-network access. **Recommended next step:** Have the CI configuration owner validate the public URL on the affected agent pool, then change the effective Maven bootstrap to that verified endpoint. If internal-first access is intentional, use an explicit, time-bounded public fallback with a pinned version and trusted checksum, preserving failure if neither download succeeds. Retain useful download diagnostics. Increasing retries alone will not resolve a persistently unreachable endpoint. Validate first that a fresh container downloads and extracts Maven and reports version `3.9.12`, then rerun the coverage configuration and confirm FE compilation and coverage reporting complete. A successful bootstrap alone does not prove the entire job passes. No repository code or CI configuration was changed during this investigation. Breakwater-GitHub-Analysis-Slot: slot_2b7cb2d89812 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
