@toandeptrai16zz

Describe the problem

When trying to install the esp32 core within a Dockerfile for a non-interactive environment, the arduino-cli core install esp32:esp32 command consistently fails due to network timeouts on large toolchain files.

Extensive debugging has revealed that this is likely a bug in v1.3.1, as the tool does not correctly detect pre-existing dependencies. Even after successfully downloading and manually extracting the main toolchain (xtensa-esp32-elf-gcc) into its correct destination directory (/root/.arduino15/packages/esp32/tools/...), the core install command completely ignores these local files. It then attempts to download a different required tool (esp-rv32) from the internet, which fails with a network timeout.

This proves the tool is not correctly checking for its own dependencies if they are already present on the system.

To reproduce

1. Use the following Dockerfile. This file programmatically downloads and manually extracts the xtensa-esp32-elf-gcc toolchain before calling core install to prove that the tool is ignored.

   # Base Image
   FROM ubuntu:22.04
   # Environment setup
   ENV DEBIAN_FRONTEND=noninteractive
   ENV PATH="/usr/local/bin:${PATH}"
   # Install dependencies, including jq for JSON parsing
   RUN apt-get update && apt-get install -y \
    openssh-server \
    sudo \
    curl \
    wget \
    vim \
    git \
    ca-certificates \
    coreutils \
    jq \
    && rm -rf /var/lib/apt/lists/*
   # Copy and install arduino-cli v1.3.1
   COPY arduino-cli_1.3.1_Linux_64bit.tar.gz /
   RUN tar -xzf /arduino-cli_1.3.1_Linux_64bit.tar.gz -C /usr/local/bin/ && \
    rm /arduino-cli_1.3.1_Linux_64bit.tar.gz && \
    chmod +x /usr/local/bin/arduino-cli
   # Initialize arduino-cli and update core index
   RUN arduino-cli config init && \
    arduino-cli config set board_manager.additional_urls [https://arduino.esp8266.com/stable/package_esp8266com_index.json](https://arduino.esp8266.com/stable/package_esp8266com_index.json) [https://dl.espressif.com/dl/package_esp32_index.json](https://dl.espressif.com/dl/package_esp32_index.json) && \
    arduino-cli core update-index
   # Install cores that work
   RUN arduino-cli core install arduino:avr
   RUN arduino-cli core install esp8266:esp8266
   # Manually download and extract the main ESP32 toolchain to prove the bug
   RUN echo "Manually downloading and extracting ESP32 toolchain..." && \
    JSON_DATA=$(jq -r '.packages[0].tools[] | select(.name == "xtensa-esp32-elf-gcc") | .systems[] | select(.host == "x86_64-pc-linux-gnu") | "\(.url) \(.version)"' /root/.arduino15/package_esp32_index.json | head -n 1) && \
    TOOL_URL=$(echo "$JSON_DATA" | awk '{print 1ドル}') && \
    TOOL_VERSION=$(echo "$JSON_DATA" | awk '{print 2ドル}') && \
    if [ -z "$TOOL_URL" ] || [ -z "$TOOL_VERSION" ]; then echo "!!! ERROR: Could not find toolchain URL or Version."; exit 1; fi && \
    DEST_PATH="/root/.arduino15/packages/esp32/tools/xtensa-esp32-elf-gcc/$TOOL_VERSION" && \
    mkdir -p "$DEST_PATH" && \
    wget -T 60 -O "/tmp/esp32-tool.tar.gz" "$TOOL_URL" && \
    tar -xf "/tmp/esp32-tool.tar.gz" -C "$DEST_PATH" --strip-components=1 && \
    rm "/tmp/esp32-tool.tar.gz" && \
    echo "Manual installation of toolchain complete."
   # Attempt to install the ESP32 core. This step will fail.
   RUN echo "Installing ESP32 core (should now skip tool download)..." && \
    arduino-cli core install esp32:esp32

2. Place the arduino-cli_1.3.1_Linux_64bit.tar.gz file in the same directory.

3. Run docker build .

Expected behavior

The arduino-cli core install esp32:esp32 command should detect the manually extracted xtensa-esp32-elf-gcc tool, recognize it as a satisfied dependency, and proceed with the installation without trying to download other tools.

Arduino CLI version

1.3.1

Operating system

Linux

Operating system version

Ubuntu 22.04 (within a Docker container).

Additional context

This issue occurs in a non-interactive Docker build environment. The root cause appears to be that the v1.3.1 downloader is not robust enough for potential network instability when downloading large toolchain files. The tool's inability to detect pre-installed dependencies makes this timeout issue impossible to work around.

Issue checklist

• I searched for previous reports in the issue tracker
• I verified the problem still occurs when using the nightly build
• My report contains all necessary details