Esp32s3 workflow downloads wrong package


Hi, I have a weird behaivor with one workflow on Github using PlatformIO.

I have the next error:


Processing esp32s3-receiver (platform: espressif32; board: esp32-s3-devkitc-1; framework: arduino)
Tool Manager: Installing espressif/toolchain-xtensa-esp32s3 @ 8.4.0+2021r2-patch3
Downloading 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Unpacking 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Tool Manager: toolchain-xtensa-esp32s3@8.4.0+2021r2-patch3 has been installed!
Tool Manager: Installing espressif/toolchain-riscv32-esp @ 8.4.0+2021r2-patch3
UnknownPackageError: Could not find the package with 'espressif/toolchain-riscv32-esp @ 8.4.0+2021r2-patch3' requirements for your system 'linux_x86_64'
Error: Process completed with exit code 1.

PlatformIO env that is failing:

extends = common
platform = espressif32
board = esp32-s3-devkitc-1
board_build.mcu = esp32s3
board_build.f_cpu = 240000000L
build_flags = 

extends = esp32s3_common
build_src_filter = -<*> +<basic-receiver/>

workflow config:

name: PlatformIO

      - master
      - '**/'

      - master

    runs-on: ubuntu-latest
      max-parallel: 1
        python-version: [3.7]
      - uses: actions/checkout@v1
      - name: Set up Python ${{ matrix.python-version }}
        uses: actions/setup-python@v1
          python-version: ${{ matrix.python-version }}
      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -U platformio
          pio pkg update
      - name: Architecture tests
        run: |
          pio run

In my local environment works fine, but it download a different package:

 - framework-arduinoespressif32 @ 3.20011.230801 (2.0.11) 
 - tool-esptoolpy @ 1.40501.0 (4.5.1) 
 - toolchain-riscv32-esp @ 8.4.0+2021r2-patch5 
 - toolchain-xtensa-esp32s3 @ 8.4.0+2021r2-patch5

In other repository I have a similar workflow also with an ESP32S3 env, and it works fine.

Some links:

workflow fail
plaformio.ini (please uncomment these lines)

Try fixing the espressif32 platform version in the esp32s3_common block to the latest 6.4.0. It’s using 4.4.0, and apparently packages that that version refers to no longer exist. If it used platform 4.4.0 it would also compiled against Arduino-ESP32 2.0.3, not 2.0.11 like in your local environment.

Thanks for your answer, but you are wrong. In the line 43 I have an override of this. The build that is failing is the env on the line 41, and it has a target to the last version of espressif32. For example this workflow works fine and it is very similar than this, and also I have this kind of overrides.

Also is clear the output that I pasted above, please check the first line:

Processing esp32s3-receiver (platform: espressif32; board: esp32-s3-devkitc-1; framework: arduino)

Well, my provisional workaround was forced the version on the esp32s3_common, but I think the issue continue, for a weird reason that I don’t know, the pipe is trying to download an outdated version, patch3 and it should be patch5.

I don’t know if maybe the problem is in these lines:

run: |
          python -m pip install --upgrade pip
          pip install -U platformio
          pio pkg update

or the PlatformIO Core is working bad?

Unfortunately this is not how this works. If platform-espressif32 was not previously installed, platform = espressif32 would download the latest version. However, since an environment is compiled before that, with espressif32@4.4.0, PlatformIO sees no need to install the Espressif32 platform since a version is already installed (or more specifically, espressif32@4.4.0 matches the SemVer espressif32). And so it uses the same 4.4.0 version. Hence why you need to pin both versions.

1 Like

Thanks for your answer. Well, if this that you wrote is true, maybe we have something wrong here, because each environment config in PlatformIO should be independent. If you don’t specify nothing (no version number), it should be download the latest stable one, (not the previous downloaded in the system), or don’t should matter the previous definitions. Like a Docker or other CI tool, the manifest is all, and the build should coherent with it.

Sadly should is different from is here.

Changing the semantics from platform = x equal platform = x@latest would probably also break some people’s project at this point. But you’re always free to open a ticket in