[Feature Request]: Check if local pack repository is available and turn missing packs warning into error

[jreineckearm]

Description

#473 introduced checks for existence of DFP/BSP referenced in the *.cbuild-run.yml file.
This didn't include the handling of locally registered pack repositories. Information about these can be extracted from CMSIS_PACK_CACHE/.Local/local_repository.pidx.

• We should extend the check to include these so that they don't flag up for pack developers.
• We should then review if to turn the warning into a critical error as originally requested. And/or if we need to refine the mechanism to go a step further and only flag a pack if its contents is really needed at runtime (like for flash algorithms).

Is this request a Security Requirement?

• Yes

Priority

Medium

Related Issues (Optional)

#473

Additional Notes (Optional)

No response

[RobertRostohar]

I'm questioning if we really need to check for packs and report warnings/errors. This is not trivial anymore when checking for local packs (arbitrary folders names based on user choice and not portable since files with absolute path might be used in the cbuild-run.yml).

Also, I don't see a lot of benefit to write a list of missing packs to a generated file that could be potentially used with cpackget. It will not work for local packs. Anyway, there are only two packs DFP and BSP that should be installed and BSP is most likely not even used. So why fail if BSP is missing but not used. Also why fail if DFP is missing but nothing is used from it (programming algorithms, ...)

In most cases, the cbuild-run.yml is generated on the fly by the tools which will already fail if packs are missing. I believe we want to address a use case where cbuild-run.yml is already generated and shared for command line usage (will anyway not work out of the box when local packs are used with files having an absolute path).

cbuild-run.yml already has all the information from the pack descriptions embedded. It only references some files from the packs (programming algorithms, svd, ...). It can also reference user provided files specified in the project.

I would therefore propose another approach:

• don't check for missing DFP/BSP when starting the debugger
• check for missing file listed in cbuild-run.yml on the fly when the file should be used
• stop the operation (example programming) if the required file is missing
• report an error that the file is missing and if it is detected that it is from a pack then print the pack name

[jkrech]

The use case behind this is the following.
In the absence of a board farm one can build github hosted application projects in github actions. The action will store the build artifacts including cbuild-run.yml as an asset that can be download, extracted and then load & run on another host connected to the board. Rather than cloning the whole repo you just load and run. pyOCD will require to have the DFP/BSP installed.

The check for the packs should be simplified. Local packs are not expected to work in the above scenario.

[RobertRostohar]

This is a very specific use case. Note, that if programming algorithms are part of the project, they would need to be included in the check out.

Local packs are not expected to work in the above scenario.

If we just check the public packs, we might show warnings about missing packs which would be misleading.

I still don't see the need for checking that the packs are installed and would rather check if the referenced files from the packs are there as described in my previous comment.

[ReinhardKeil]

The orignal request was "When a cbuild-run.yml file refers packs and a command (i.e. load) is executed that requires algorithms of a missing packs".

This implies a two step approach:

• identify missing algorithms
• if algorithm is from a pack, create a file pack.cmd

We need a work flow for CI usage of pyOCD where only the out directory is used. Think about using the artifacts on https://github.com/Arm-Examples/cmsis-mlek-examples/actions/runs/17127700978 in a CI test farm that just flashes the images.

[RobertRostohar]

That is in line with my suggestion. I would just rather print directly which pack to install and how, rather than creating a pack.cmd. It is anyway just one DFP and potential one BSP.

[jreineckearm]

Expected to be addressed soon after upcoming release.