Mbed-cli: mbed deploy timing out due to caching after five minutes

[teetak01]

A customer reported an issue in https://github.com/ARMmbed/mbed-cloud-client-yocto-setup/issues/21

## $ time mbed deploy --protocol git -v
[mbed] Working path "/media/xxx/WORKDIR/YOCTOMBED/mbed-cloud-client-yocto-setup" (program)
[mbed] Adding library "poky" from "git://git.yoctoproject.org/poky" at rev #d240b885f26e
[mbed] Trying to guess source control management tool. Supported SCMs: bld, git, hg
[mbed] Found matching cached repository in "/home/xxx/.mbed/mbed-cache/git.yoctoproject.org/poky"
[mbed] Carbon copy from "/home/xxx/.mbed/mbed-cache/git.yoctoproject.org/poky" to "/media/xxx/WORKDIR/YOCTOMBED/mbed-cloud-client-yocto-setup/poky"
[mbed] ERROR: Exceeded 5 minutes limit while waiting for other process to finish caching
real    4m59,502s
user    0m0,151s
sys 0m0,042s

It would seem that the caching is stuck or something else goes wrong. As a workaround, when caching is disabled, the deployment goes through fine.

Is this expected behaviour, or is the code hitting on some problem case which causes the caching to hang indefinately?

[theotherjimmy]

Weird. that probably should be quick. Man those messages are full of jargon too.

[teetak01]

@theotherjimmy this is for compiling Device Management Client on Raspberry Pi3 following this tutorial: https://cloud.mbed.com/docs/current/connecting/linux-on-raspberry-pi-3.html

Just wondering what might go wrong here, as I have not seen such issue before.

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-911

[linlingao]

@teetak01 I ran into similar issue. I had to disable cache. My problem appears to caused by newly imaged computer. It would be interesting to know if this user also used a newly imaged computer.

[theotherjimmy]

@teetak01 That's an interesting environment you have there. That document needs to be corrected, as --protocol git does not make sense, nor does it do anything.

[teetak01]

@theotherjimmy can you clarify that? This is from the mbed-cli help

  --protocol [PROTOCOL]
                        Transport protocol for the source control management.
                        Supported: https, http, ssh, git. Default: inferred
                        from URL.

What is the git supposed to do or is it some no-op flag? I have vague recollection that we needed the to have the mixed deployment to work in both private and public repositories for the yocto example, and if you had local/global defines for protocol, it broke one or the other, so the "git" gave some "default" behavior.

Maybe the "git" option really should mean: "Use whatever the default is for the .lib file" as that is what we actually have been expecting to work (afaik).

We wanted to use mbed-cli as common deployment tool for all examples, even if they have nothing to do with Mbed OS, just to keep things streamlined.

Anyways I think this cache-hanging is not related to the "git" option, but something that might happen with Ubuntu 18.04 (which afaik the customer in this case was also using).

[40Grit]

@teetak01

I faced the same problem regarding using mbed-cli for dependency management.

After trying many unsuitable tools, Google repo included. We settled on Peru. Gitman is another that would work just as well.

Till mbed-cli supports the same features it is worth the extra dev dependency.

https://github.com/buildinspace/peru
https://github.com/jacebrowning/gitman

[adbridge]

Apologies, this was closed in error by the automated bot - re-opening.

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/IOTBTOOL-464

[mbos-stress]

Why on earth are there timeouts for anything? I keep running into this and it just wastes my time by making me restart things when they would have finished in another ten minutes if it weren't for the timeout?

[aazavid]

We have the same problem. Is work being done on this issue?