Hi @andreas_9392 ,
That configuration is not supported and will not work; You'll need to configure https://proget.mycompany.com/ or use a port.
Thanks,
Alana
Hi @andreas_9392 ,
That configuration is not supported and will not work; You'll need to configure https://proget.mycompany.com/ or use a port.
Thanks,
Alana
This would be a relatively easys change to make, but we'd like to be able to test it against a public repository that has noarch packages included in its index. The https://dl-cdn.alpinelinux.org/alpine/v3.21/main/x86_64/APKINDEX.tar.gz index file doesn't seem to have anything except x86_64 packages in it. Is there a good public repo we can use as a solid source of working example data?
@wechselberg-nisboerge_3629 great news, thanks! Well it'll be in the upcoming release (2025.13) in that case :)
@wechselberg-nisboerge_3629 can you check it out again? Should be there now :)
Hi @wechselberg-nisboerge_3629 ,
Thanks for sharing that; sadly I'm still at a total loss here 
But I did make a change that I think should work, or at least give us a different error.... can you try upgrading to inedo/proget:25.0.14-ci.7?
The change is in that build. OF course, you can easily downgrade later.
Thanks,
Alana
Hi @Anthony ,
When you use SHCall, it's translated into a remote SSH command that includes all arguments inline on the shell. Basically something like ssh user@host bash -c '...'
However, there is an OS-enforced limit on how long this can be, which is typically between ~32K and ~64K characters. It looks like you're there exactly, and you may be able to see this limit with getconf ARG_MAX. Note that you would also get this error if you did ssh user@host bash -c 'echo "Really long....."'.
So bottom line -- this is an OS/SSH limit. To work-around it, you can just write out $arg to a file, and have your script read in that file.
Thanks,
Alana
Thanks @wechselberg-nisboerge_3629 , Exactly what I was looking for!
Can you provide some more information about this image? Basically I'm trying to find the layer / mediatype / size. I believe these commands will do it:
docker image inspect vl-dev-repo.ki.lan/sst-coco-oci-prod/sub-coco-cli:test --format '{{json .RootFS.Layers}}' | jq .
docker history vl-dev-repo.ki.lan/sst-coco-oci-prod/sub-coco-cli:test
Thanks,
Alana
Hi @koksime-yap_5909 ,
[1] I would do localhost as to reduce network traffic; a lot of time, "loopback" connections are handled in software and never make it to the network hardware
[2] multiple copies of the package are stored
In general, you should use data-deduplication anyway. Even with out self-connectors, we've seen a 90% reduction in space due to the nature of what's stored (i.e. nearly identical versions).
Thanks,
Alana
@wechselberg-nisboerge_3629 the main thing I'm looking for is the HTTP access logs - we have 1.5 Entires before (PATCH-finish, PUT-Start, PUT-finish), so seeing more would be really helpful.
What's odd is seeing the "retrying..."
@wechselberg-nisboerge_3629 thanks for comfirming!
Any chance you can get more entries from the container log? It'd be really helpful to see more requests going back/forth. This is just such a strange behavior given the seeming simplicity of your image
Also, there should be an option, in ProGet 2025.12, to enable web logging (Admin > HTTPS Logging); it's a brand new feature, but it writes logs to a log file.