Use arm-none-eabi-gcc-action #6532
Conversation
|
I have made similar PR to tinyuf2 and nrf52 bootloader repo
It works like a charm, and tidy up yml file as well :) |
|
There are multiple instances of a cache conflict going on in the first set of builds: |
This is rather normal for initial run, when each of the matrix instance try to add toolchain to cache (only first one succeeded to cache). It will go away afterwards, since toolchain already cached. You could simply re-run the ci, it this warnings will disappear. |
|
You could have the test job do it too since it runs before the builds. |
As long as it's then part of the cache, that sounds great. I think we have like 60 jobs trying to fetch it at the same time, and all are refetching because of the collision. |
|
As long as we don't care about adding an unnecessary ~6s to the 'test job' whether it's needed or not ... I think that what @hathach is trying to say is, while the message looks troubling due to its unfamiliarity it doesn't indicate a problem; and once the PR has been run on main once and the cache is populated, the message shouldn't occur anymore anyway. Until we cleared the cache or selected a different gcc version that would use a different cache key. |
|
That said, googling about the message led me to concerning problems that DO show this message and where the suggested remedy is to change the cache key: actions/cache#485 (comment) -- problem being, while we can and have done that with esp-idf in the past, there's no provision that I saw to make this action use a different key. hm. |
|
I'm not thinking the message indicates an error, but it's an inefficiency. The first 60 or so jobs are not benefiting from the cache, it would appear. This is a specialized action, which downloads specific files from specific places. Is there a more generalized action or mechanism we could use to download particular files (in the test job or some other precursor job), that would allow us to clear the cache or change the key if necesary? I haven't yet tried to understand what the espressif jobs do in terms of caching. |
|
.. but only the first time it runs on the main branch. On the next run, all the builds will see the cache and use it. |
oooh! I thought it was only per PR run. |
I would approve this but still a bit worried about getting stuck due to this. |
|
maybe the author of the action can explain this better. @carlosperate I hope you have an minute or two to clarify the cache warnings, If not sorry for the mention |
|
Hi all, and thanks for the tag @hathach! The action will first try to get GCC from the cache, and if that fails (which would be expected the first time it runs), it will download it from the Arm servers, set it up, and only then try to save it to the cache. In this case as several of the parallel jobs are attempting to save to the same cache entry at the same time, so we get the warnings discussed here. These are raise as warnings, but the action has already set up GCC and the rest of the job should continue as normal. As a simple test, I've run this in my fork:
I haven't look at all of the jobs, as there are quite a few, but I've looked at a couple of random ones, and at some point the first run here is already finding matches in the cache, like this one: https://github.com/adafruit/circuitpython/runs/7103081116?check_suite_focus=true#step:5:12 Hope that clarifies things, let me know if I left something out |
@tannewt noticed there's an action to download the embedded arm compiler. it might even be faster, as it uses the actions cache to store the compiler.