Back when I wrote this, I thought HPO does something magical for overwriting the general args of the task when cloning.
Turns out it just was my code that was missing a more explicit set_parameter for this environment path.

It comes from the PipelineDecorator.pipeline I assume or from PipelineDecorator.component

The installed packages of the task say this:

# Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0]

PyYAML == 6.0.1
clearml == 1.15.1
google google_api_core
google_cloud_storage == 2.16.0
ultralytics == 8.2.2

I do not know where the google_api_core comes from and I'd like to remove it.

Hey. I should have closed this..

The thing that I was looking for is called set_parameter on the task.
The HPO uses a task I created previously and I had trouble with that, since it contained a path, which wasn't available on the colab instance.
I fixed my code, so it always updates this parameter depending on the environment.

It was less of an HPO issue, more of a programming failure on the function, which didn't properly update the parameter, even though I thought it should.

Not that I would know of..

I attached the possible problematic argument.
The strings are just regular string, nothing fancy there.

args :
{'epochs': 3, 'imgsz': 480, 'data': '/home/rini-debian/git-stash/lvgl-ui-detector/datasets/ui_randoms.yaml'}

model_variant :
yolov8n

dataset_id :
50e10f640d7548458d9c38ab9aac571b

This is the full log of the task.

I am trying to run HPO.

Is there some verbose mode I could run it with?

1.15.1

If there's some or any mechanism that would allow me to constrain what the task sees, it would really help me alot.

Alright cool!
I will check it out and let you know what it was.

That is unfortunate.

Yea, but even though it's cached, it takes quite a long time, because my project has really alot of submodules, due to the submodules having their own submodules as well.

I don't really understand why fetching the submodules is the default.

Sure can do

Yea, I get that.. But it's really hard to tell what's causing it due to the "<unknown>"

Alright, good to know.

I cleared the vcs cache manually already, it results in the same behaviour illustrated above
(allthough the logs show that it used the cache, I had another run without cache - but don't have the logs from that)

Here are the codefiles for my pipelines.

They do not work yet, I am struggling with the pipeline stuff quite a bit.

But both pipelines always give these warnings.

On another attempt with a cleaned repository (no dirty commits) I get the same result, even though it states that it got a new commit id, so I'm at a loss at what is actually going wrong here:

`Using cached repository in "/root/.clearml/vcs-cache/lvgl-ui-detector.git.7c8ae2688810ceed26c1ebcc1e911cf2/lvgl-ui-detector.git"
remote: Enumerating objects: 11, done.
remote: Counting objects: 100% (11/11), done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 8 (delta 4), reused 7 ...

Hi @<1523701087100473344:profile|SuccessfulKoala55>

I am using 1.8.0 for the clearml-agent.

Attached is the logfile.

No idea what's going on now, but I cannot reproduce the behaviour either.. also tried my old code posted here, but the warning doesn't pop up anymore.

I will inform once it pops again and will use the provided traceback function then.

I have a slight suspicion that it was indeed environment based on my local machine, but I have no idea what is the trigger for that.

It may or may not be related to this

2024-04-29 23:38:25,932 - clearml.Task - WARNING - Parameters must be of builtin ty...

My experiments are all using YOLOv8 and they contain the data from what is gathered there automatically

I don’t know what would cause slowness

I ‘ m using the app.clearml server

What’s considered large in that case?

Hem, yeah might be the case.

If it were possible to override the checkout behaviour I would ignore all submodules anyways, but in the documentation of clearml.conf as well as the pipeline decorator I couldn't find anything that would allow me doing that.

Any help would be greatly appreciated