Tests fail when not ran in Arduino CLI's Git repository

Describe the problem

Hi, currently I'm interested in getting arduino-cli package to the Alpine Linux repositories (I know that musl can be of issue here - that's why I add gcompat to the dependencies and install gcc-avr and avrdude from package manager). However, there is a big problem which I am experiencing right now: a lot of tests fail with Error searching for repository root path message despite I run them in not fancy fashion at all (with simple go-task go:test).

Also I have a question. According to the logs, some architectures fail other many tests because not every go module supports all architectures. Is this a valid reason to disable arduino-cli support on such architectures or I should just remove these tests on certain architectures?

Recipe according to which arduino-cli is built:

https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/40647/diffs

Build logs:

x86_64: https://gitlab.alpinelinux.org/grikir02/aports/-/jobs/885526/raw x86: https://gitlab.alpinelinux.org/grikir02/aports/-/jobs/885527/raw aarch64: https://gitlab.alpinelinux.org/grikir02/aports/-/jobs/885530/raw armv7: https://gitlab.alpinelinux.org/grikir02/aports/-/jobs/885531/raw armhf: https://gitlab.alpinelinux.org/grikir02/aports/-/jobs/885532/raw ppc64le: https://gitlab.alpinelinux.org/grikir02/aports/-/jobs/885529/raw s390x: https://gitlab.alpinelinux.org/grikir02/aports/-/jobs/885528/raw

Thanks!

To reproduce

Run go-task go:test on an Alpine Linux package builder.

Expected behavior

All tests pass at least for x86_64 architecture.

Arduino CLI version

13f22553fbddeb1f419c351baf30e209e6da3248

Operating system

Linux

Operating system version

Alpine Linux Edge

Additional context

No response

Issue checklist

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

Hi @txgk, thanks for your interest in this project. Firstly, I don't think you'll need avrdude and gcc-avr. Avrdude is a tool used for the upload of the compiled code on the microcontroller, and gcc-avr is the toolchain used to compile that code. They are provided when you run arduino-cli core install arduino:avr. I have doubts if they will work or not.. AFAIK they are not built with alpine linux in mind, but could be a nice experiment to try it out.

a lot of tests fail with Error searching for repository root path message

Regarding this I think I found the problem: if you check the stack trace linked here -> https://github.com/arduino/arduino-cli/blob/c48844ba722f99bb52a4c44a982bdc41a138b6eb/internal/integrationtest/arduino-cli.go#L44 you can see that it's searching for the root of the repository by locating the .git file which apparently is not present even before reaching that point, see here. My guess is that getting the source code this way is not ideal because it does not have the .git file inside the archive. See by yourself downloading https://github.com/arduino/arduino-cli/archive/13f22553fbddeb1f419c351baf30e209e6da3248/arduino-cli-13f22553fbddeb1f419c351baf30e209e6da3248.tar.gz

My recommendation regarding this is to download the source code by git cloning the repository and checking out a release tag, otherwise when running arduino-cli version it will print something like arduino-cli Version: git-snapshot Commit: 95729fc4 Date: 2022-10-26T10:34:40Z and not arduino-cli Version: 0.28.0 Commit: 06fb1909 Date: 2022-10-18T15:53:04Z

Hi, thank you for detailed answer.

Firstly, I don't think you'll need avrdude and gcc-avr. Avrdude is a tool used for the upload of the compiled code on the microcontroller, and gcc-avr is the toolchain used to compile that code. They are provided when you run arduino-cli core install arduino:avr. I have doubts if they will work or not.. AFAIK they are not built with alpine linux in mind, but could be a nice experiment to try it out.

As far as I know arduino-cli downloads binaries that are linked against glibc. If it's true then it is a big flaw. Is there a way for me to force arduino-cli to use system-provided avr tools instead of fetching ones linked against glibc? I think that'd be a very useful feature.

you can see that it's searching for the root of the repository by locating the .git file which apparently is not present even before reaching that point, see here.

I checked and even tests in release tarballs (without git artifacts) fail because there's no .git directory. I'd say it's not very efficient for package repositories to clone git every time that way and for point releases in particular. Requiring git artifacts in the tests looks gruff and it seems to me that this situation should to move in a more rational direction.

Here are new logs with build from git clone (now some version test fails...):

x86_64: https://gitlab.alpinelinux.org/grikir02/aports/-/jobs/886233/raw aarch64: https://gitlab.alpinelinux.org/grikir02/aports/-/jobs/886237/raw ppc64le: https://gitlab.alpinelinux.org/grikir02/aports/-/jobs/886236/raw

As far as I know arduino-cli downloads binaries that are linked against glibc. If it's true then it is a big flaw. Is there a way for me to force arduino-cli to use system-provided avr tools instead of fetching ones linked against glibc? I think that'd be a very useful feature.

Unfortunately, this is not possible as every microcontroller platform requires a very specific set of tools (with very specific versions)... sometimes even changing a minor release of one of them can break a platform (also the libraries the tools are linked to may create problems, libusb is one of them).

We used to not bundle avr-gcc and avrdude with the Arduino IDE for Linux, relying on the tools that were system-provided: the result was that the Linux distribution of the Arduino IDE was always broken due to avr-gcc or avrdude version shipped with the distro.

This is a general problem, not only for AVR platform but also for all the other microcontrollers. BTW some platforms may decide autonomously to rely on some system-installed tools, for example, ESP32 platforms require python3 to be installed (see below).

I checked and even tests in release tarballs (without git artifacts) fail because there's no .git directory. I'd say it's not very efficient for package repositories to clone git every time that way and for point releases in particular. Requiring git artifacts in the tests looks gruff and it seems to me that this situation should to move in a more rational direction.

We may check for another file in the root folder, like TaskFile.yml, no problem for that. We opted for .git since it's a file that we will always have, no matter which other tool we decide to use.

Here are new logs with build from git clone (now some version test fails...):

I see that one of the failure is:

[90m>>> Running: [0m[93m/builds/grikir02/aports/testing/arduino-cli/src/arduino-cli-0_git20221025/arduino-cli compile --libraries /tmp/cli4024095848/sketch_with_multiple_custom_libraries/libraries1 --libraries /tmp/cli4024095848/sketch_with_multiple_custom_libraries/libraries2 -b esp8266:esp8266:nodemcu:xtal=80,vt=heap,eesz=4M1M,wipe=none,baud=115200 /tmp/cli4024095848/sketch_with_multiple_custom_libraries[0m
env: can't execute 'python3': No such file or directory

Error during build: exit status 127
[90m<<< Run completed (err = exit status 1)[0m
    compile_part_2_test.go:104: 
            Error Trace:    /builds/grikir02/aports/testing/arduino-cli/src/arduino-cli-0_git20221025/internal/integrationtest/compile/compile_part_2_test.go:104
            Error:          Received unexpected error:
                            exit status 1
            Test:           TestCompileWithCustomLibraries
--- FAIL: TestCompileWithCustomLibraries (108.33s)

this is a missing python3.

Here are new logs with build from git clone (now some version test fails...):

I cannot find them, maybe you could provide a copy/paste of the snippet of the log?

Hi, thank you for detailed answer!

Unfortunately, this is not possible as every microcontroller platform requires a very specific set of tools (with very specific versions)... sometimes even changing a minor release of one of them can break a platform (also the libraries the tools are linked to may create problems, libusb is one of them).

We used to not bundle avr-gcc and avrdude with the Arduino IDE for Linux, relying on the tools that were system-provided: the result was that the Linux distribution of the Arduino IDE was always broken due to avr-gcc or avrdude version shipped with the distro.

I understand that. Going for system-provided tools by default wouldn't be really practical in this case, yeah. But I want to believe that adding --use-system-tools argument or something like that to arduino-cli is not difficult to implement (I may be wrong; I don't want to make an impression like I demand it, I just let you know that it would be nice to have it for users with libc other than glibc (Linux distributions based on musl, BSDs, etc)). It may be buggy in some cases but it would at least run, right?

We may check for another file in the root folder, like TaskFile.yml, no problem for that. We opted for .git since it's a file that we will always have, no matter which other tool we decide to use.

It would be nice if release tarballs would check this TaskFile.yml rather than absent .git directory :)

I see that one of the failure this is a missing python3

Thanks, added python3 as a dependency now.

I cannot find them, maybe you could provide a copy/paste of the snippet of the log?

I think I was wrong here. I guess I overlooked, sorry for that

arduino / arduino-cli