With the warning ?
I was able to reproduce it on the old versions, but it seems fixed on the latest from GitHub.

Sorry, I meant the "origin" part. The warning is no more.

Okay, progress.
What are you getting when running the following from the git repo folder:
git ls-remote --get-url origin

Take a guess 😂 (it's "origin")

LOL, could be there is no remote repository ?

there is - it's called "github"

✦2 ❯ git remote show
github

that's the entire repo link ? not something like https://github.com/ ... ?

✦ ❯ git remote -v github git@github.com:biocatchltd/volt.git (fetch) github git@github.com:biocatchltd/volt.git (push)

okay the odd thing git ls-remote --get-url origin should have returned the same...
what's your git version? (git --version)

Oh i get it now, can you test:
git ls-remote --get-url githuband then
git ls-remote --get-url

` radu on vm-aimbrain-01 in experiments/runners/all via 🐍 v3.8.5 via C volt
❯ git ls-remote --get-url github
github

radu on vm-aimbrain-01 in experiments/runners/all via 🐍 v3.8.5 via C volt
❯ git ls-remote --get-url
fatal: No remote configured to list refs from.

radu on vm-aimbrain-01 in experiments/runners/all via 🐍 v3.8.5 via C volt
❯ git --version
git version 2.17.1 `

Okay let me check if I can test on this git version.

based on this one:
https://stackoverflow.com/questions/31436407/git-ls-remote-returns-fatal-no-remote-configured-to-list-refs-from
I think this is a specific issue of the local git repo configuration, can you verify
(btw: I tested with git 2.17.1 git ls-remote --get-url will return the remote url, without an error)

The problem appears to be related to the lack of an "origin" remote. However, I think the configuration is perfectly legitimate, so maybe there's a better alternative than relying on the behaviour of git ls-remote --get-url .

I will take any suggestion 🙂
git remote -v could be a good start but I'm not familiar with the output structure, is there a template for parsing ?

The template appears to be <alias> <url> <fetch|push> .
The .git/config file has sections for each remote too. Example:
[remote "github"] url = git@github.com:biocatchltd/volt.git fetch = +refs/heads/:refs/remotes/github/Would be nice to report which remote the checked out branch actually tracks.

Unfortunately it still happens 😞 :
` Epoch 51: 100%|███████████████████████████████████████████████████████████| 361/361 [02:52<00:00, 2.10it/s, loss=0.169, v_num=9-29]
2021-09-17 09:58:22,253 - clearml.Task - INFO - Waiting for repository detection and full package requirement analysis
2021-09-17 10:03:22,254 - clearml.Task - INFO - Repository and package analysis timed out (300.0 sec), giving up
2021-09-17 10:03:22,313 - clearml.Task - WARNING - Failed auto-detecting task repository: no info for [PosixPath('/datadrive2/radu/volt/volt/scripts'), PosixPath('/datadrive2/radu/volt/volt/scripts')] (exception SystemExit() not a BaseException subclass)

radu on vm-aimbrain-01 in experiments/runners/all via 🐍 v3.8.5 via C volt took 3h8m43s
❯ python -c "import clearml; print(clearml.version)"
1.0.6rc2 `

WittyOwl57 that is odd there is a specific catch for SystemExit
https://github.com/allegroai/clearml/blob/51d70efbffa87aa41b46c2024918bf4c584f29cf/clearml/backend_interface/task/repo/scriptinfo.py#L773
How do I reproduce this issue/warning ?
Also: "Repository and package analysis timed out (300.0 sec), giving up" seriously ove 5 minutes ?! how large is the git repo?

` radu on vm-aimbrain-01 in volt on  rg/dev [$] is 📦 v7.0.1 via 🐍 v3.8.5 via C volt
✦2 ❯ git status
On branch rg/dev
nothing to commit, working tree clean

radu on vm-aimbrain-01 in volt on  rg/dev [$] is 📦 v7.0.1 via 🐍 v3.8.5 via C volt
✦ ❯ du -sh .
35M . `

Must be something else foul at play here..

I think, this all ties into the none-standard git repo definition. I cannot find any other reason for it. Is it actually stuck for 5 min at the end of the process, waiting for the repo detection ?

yep

you think that simply adding origin will fix this - I really don't mind doing that

Can you verify it fixes the timeout issue as well? (or some insight on how to reproduce the issue?)

I'll let you know asap

Thanks!

So does that mean "origin" solves the issue ?

We can't really know (possibly ever 🙂 ), but if the bug happens again I'll be sure to report it here.