administrators

Hi @henderkes,

Thanks for sending those packages over. I was able to recreate some issues with those packages and we are currently still looking for the cause. I'll send over an update once I have a bit more information.

Thanks,
Rich

Hi @koksime-yap_5909,

There are certain types of OCI images that are not supported in ProGet (covered in this forums post), but the application/vnd.oci.image.manifest.v1+json image type manifest is supported. I'm guessing this is a quirk with Artifactory. What I have learned through implementing this importer is that Artifactory is very dependent on the order of accept headers. It is possible that the order is not quite right. Our order for the importers are:

private static HttpRequestMessage CreateDockerHttpRequest(HttpMethod method, string url)
{
    var request = new HttpRequestMessage(method, url);
    // Order matters here, especially with Artifactory
    request.Headers.Accept.Add(new("application/vnd.docker.distribution.manifest.v2+json"));
    request.Headers.Accept.Add(new("application/vnd.docker.distribution.manifest.list.v2+json"));
    request.Headers.Accept.Add(new("application/vnd.docker.distribution.manifest.v1+prettyjws"));
    request.Headers.Accept.Add(new("application/json"));
    request.Headers.Accept.Add(new("application/vnd.oci.image.manifest.v1+json"));
    request.Headers.Accept.Add(new("application/vnd.oci.image.index.v1+json"));

    return request;
}

Is it possible to share an example Docker file that we could build an image that has this import image? That way I can verify it mixed with standard Docker images.

Thanks,
Rich

Hi @henderkes,

I did try to download that script to extract the repo you were referring to, but Alpine does not have bash installed, only ash, so I get an error when attempting to run it. Could you please provide me a direct link? To be honest, this all screams a configuration error on Alpine or an issue with the APK directly.

In my test, I created a feed in ProGet with a connector created pointing to "https://repos.zend.com/zendphp/apk_alpine320/x86_64/". I then added my feed to alpine, apk update, and then apk add php85zend. Everything worked as expected.

Thanks,
Rich

Hi @henderkes,

Can you provide where you are getting your test packages from? I have a feeling it has to do with them more than the index. I setup the environment you specified with alpine packages I pulled from Zend PHP and had no issues. I was able to update the index and install multiple packages.

Thanks,
Rich

Hi @henderkes,

Thank you for sending all this over! We are going to dig into this a bit further and will let you know what we find.

Thanks,
Rich

@jonathan-werder_8656 great point, we'll add that to our list to document! Thanks for pointing it out

Hi @tim-vanryzin_8423 ,

Great question on developer experience! We're very curious to learn that ourselves, so please let us know as you implement it.

First and foremost, if you haven't already, check out the Recently Published & Aged Packages rules blog article to see how this works and our current advice. FYI - we are likely going to change the best practices guidance in 2026 to discourage download blocking.

From an API/technical standpoint, it's simply not possible to "hide" the fact that 1.12.15 is the latest version. So, if you have a connector, ProGet will report the latest version as reported by the connector.

But even it were technically possible, there's no simply great developer experience here. Keep in mind that most never look at the ProGet ui -- they configure things once, and forgeet about it.

So really, it's just a question of when you want the developer to find out they can't use Xyz-1.12.15. Here are the general options:

• Manual Curation (no connectors) - it's always going to be on nuget.org / npmjs.org, so even if you manually curate every page in ProGet, they'll know it exists and will be confused why it's not on ProGet; they may not even know who to ask
• Download blocking - you could simply block downloads of newest packages, but that's just going to look like random "400 errors" to developers and they will become frustrated
• Build Auditing - run pgutil builds audit on your build server, and you can see if the packages are noncompliant; this is where we are shifting our advice, as a failed build at that stage will be so much more obvious than a 400 buried in a package restore step

Ultimately this requires training developers to use lock files and not always get latest. That's why we are shifting to pgutil builds audit -- it's almost self-training. When their builds fail, they will see the reason clearly and should be able to adjust their code/configuration to not use a non-compliant version.

-- Dean

Thanks! This will be fixed in today's release of ProGet 2025.17 as PG-3187.

Hi @henderkes,

Based on the Alpine's Package Keeper documentation, although the apk-tools are at version 3, the index and packages are still v2. From what I can tell, there is no timeline on when the v2 Index format will be dropped and the use of the v3 index is an opt-in feature. Currently ProGet only supports the v2 index and package format. I have added apk V3 support to be reviewed for ProGet 2026.

Could you please provide a little more details around what operations are giving you the errors and the log output that shows the error?

Thanks,
Rich

Hi @jolaka9284_9458,

Thanks for providing all these details. I was able to pinpoint the reason for the slow down and why it specifically happens on some crates and not others. This is related to some code that we have to determine when to point cargo to pull dependencies from ProGet vs crates.io. Specifically this comes from cargo's API specs for dependencies:

registry — cargo metadata uses a value of null to indicate that the dependency comes from crates.io. The index uses a value of null to indicate that the dependency comes from the same registry as the index. When creating an index entry, a registry other than crates.io should translate a value of null to be https://github.com/rust-lang/crates.io-index and translate a URL that matches the current index to be null.

As you can see, the value specified in the metadata is different than the value the index needs to return. In ProGet, we will return null if the package exists in the feed (including connectors) and https://github.com/rust-lang/crates.io-index if it does not. This is to support the case when ProGet is not used as a mirror and instead for only local crates. Unfortunately the use ProGet as a mirror option is stored only in the client config and is not sent to ProGet.

This is the reason why crates with a lot of dependencies take longer to generate the index than ones that don't and why you'll occasionally get timeouts, but after the retry it works. We have some caching on this to help with performance, but it's not a forever cache.

I'm going to work on some potential improvements for this and will let you know when I have a solution ready. Unfortunately, the only workaround we have for this currently is to use a package approval workflow (like our npm Package Approval blog article).

Thanks,
Rich