Posts made by rhessinger

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

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

Hi @jolaka9284_9458,

Can you please answer the following so I can get an idea of your environment setup?

• What version of ProGet you are running?
• Is your config.toml configured to proxy all cargo requests through ProGet (overriding [source.crates-io])?
• Do you have connector package caching and/or metadata caching enabled?
• Are you using SQL Server or PostgreSQL (the embedded database, InedoDB, etc..)?

I'm not able to test against Artifactory very easily, but testing against crates.io. I'm not seeing a huge difference in speed (~20 seconds in your test case). In my testing, the time varies greatly based on the number of versions a package has and speeds up significantly once the indexes have been cached locally.

My theory is that Artifactory caches these indexes on disk on the server or is not returning the complete dataset (hosted vs local), compared to ProGet where we create the package index each time it's requested and leave the local index caching to cargo. When ProGet generates it's package index, it reaches out to any connectors on the feed and then merges them with the local package versions stored in ProGet.

There are pros and cons to each solution and are only really noticeable when the local cargo cache is cleared. When cargo has a local cache, it will send a If-Modified-Since header in its index request, allowing that index to be skipped if nothing has changed recently.

Is it also possible to get a list of your HTTP requests and timings made during these? I don't need the response body, but the URL Path (host and feed names can be anonymized), response time taken, and response code is all I really need. In ProGet 2025, you can enable HTTP Request Logging to obtain these.

Thanks,
Rich

Hi @coboj59760_1341,

I just pushed a pre-release that includes the fix. Please install ProGet 25.0.17-ci.12 and that should resolve this issue. Please let us know if that resolves your issue.

Thanks,
Rich

Hi @coboj59760_1341,

Thank you very much for all the information on how to recreate the error. In Cargo 1.84.0 (released in January 2025), they changed the default value for default_features from false to true. In the case of the examples you provided, these cargo manifests did specify a value for default_features causing it to change to false once the package is cached in ProGet.

I have created a ticket, PG-3182, to track the fix. This will be released in next weeks release of ProGet. I can also provide a pre-release version of ProGet if you would like. Just let me know!

Thanks,
Rich

Hi @koksime-yap_5909,

Sounds good. The fix will be released on Friday December 19th.

Thanks,
rich

Hi @koksime-yap_5909,

Thank you very much for all the information. I was able to recreate your issue and I'm working on a fix right now. I have created a ticket, PG-3178, to track the fix and should have it resolved shortly. The next release is Friday of next week, but I can provide you with a pre-release to try as soon as the fix is ready if you would like. Please let me know.

Thanks,
Rich

Hi @koksime-yap_5909,

Thanks for clarifying that for me. In my testing, the name property always started with repository/<<REPOSITTORY_NAME>>/.... I'm going to dig into this further and should have an update for you tomorrow. One last question, do you have any rules in your reverse-proxy that would be stripping that out of components API?

Thanks,
Rich

Hi @koksime-yap_5909,

Thanks for sending this over! It will take me a but to dig through this. Just a couple of quick follow up questions:

1. What is psuedo-group? Is that a repository/registry name?
2. What is subgrouping/groups? It may be helpful to see a screenshot of this example inside of Nexus.

Thanks,
Rich

Hi @koksime-yap_5909,

Thanks for following up! Is it possible to share the contents of the JSON your API generates? You can do that by logging into Nexus and entering the following URL in your browser: https://«NEXUS_HOST_AND_PORT»/service/rest/v1/components?repository=«REPOSITORY_NAME»

Please not the Repository Name is your Docker Registry name.

The code does some stuff to strip off the registry name so only the namespace and image name are left. I'm guessing that something is being returned slightly differently. Can you also tell us what version of Nexus you are running? It might help so I can do more testing with that version.

Thanks,
Rich

Hi @koksime-yap_5909,

The separate proxy server port is what is causing the import issue with this. After looking at this further, the main issue is that specified httpPort is overriding the port, even when an https:// URL is being used. I created a ticket, PG-3155, to fix that and add the ability to override the URL used for the Docker API. This fix will be released in ProGet 2025.15. If you are interested, I can get you a pre-release build with the fix in it either later today or tomorrow. Just let me know!

Thanks,
Rich

Hi @felfert,

Thanks for sending that. Since there are no errors right at the beginning, there was no errors in the upgrade process. Most likely restarting the container will resolve the schema issue. I have created a ticket, PG-3154, to add some more output logging in the schema update code to better understand the source of this issue going forward. Please let us know if restarting the container after updating to the 2025.14 does not resolve the schema version mismatch.

Thanks,
Rich

Hi @felfert,

The database schema is updated when the container starts. In the cases where you get a schema mismatch, typically just restarting the container will resolve the issue. This seems to happen every now and again, only in Docker, but we have been unable to reproduce it on our end to fix it. Next time you attempt to update to the new image and see this issue, could you provide us with the output from the start of your container?

Thanks,
Rich

Hi @koksime-yap_5909,

ProGet uses a combination of the Nexus REST API and the Docker API to pull images from Nexus. Just like packages, only local images will be pulled (as in only hosted Nexus Docker registries are supported). The basic process is:

1. Get a list of images using the Nexus components API.
2. Get the Docker API endpoint using the Nexus registries API (this is what you would use in the Docker client)
3. Pull the image (manifest, layers, etc...) using the Nexus Docker API

I'm guessing the error is occurring building the URL to Docker API endpoint. When you say that you are using an external proxy, did you configure the subdomain and port in Nexus to be the subdomain and port of your proxy? Would you also be able to send us the JSON that is returned for the following GET request in the Nexus API?

https://«NEXUS_HOST_AND_PORT»/service/rest/v1/repositories/docker/hosted/«NEXUS_DOCKER_REGISTRY_NAME»

If you can send me the value for the url property and the object for docker property, I can tell you what URL ProGet using to connect to the Docker API. Feel free to obfuscate the host name, subdomain (if configured), and registry name. The JSON will look something like this:

{
  "name": "internal",
  "format": "docker",
  "type": "hosted",
  "url": "http://localhost:8081/repository/docker-example",
  
...

  "docker": {
    "v1Enabled": false,
    "forceBasicAuth": true,
    "httpPort": 8082,
    "httpsPort": 8083,
    "subdomain": "docker-a",
    "pathEnabled": true
  }
}

Thanks,
Rich

Hi @lukas-herzog_4227,

Please try to restart your ProGet container. That will trigger another check for the database upgrade and should fix the issue. If restarting your container does not fix the issue, please let us know.

Thanks,
Rich

Hi @aristo_4359,

It looks like this should be possible with most of the services. I created a ticket, PG-3117, to investigate and add the feature. We will let you know if we find anything that will prevent us from implementing this.

Thanks,
Rich

Hi @aristo_4359,

Thank you for sending that over. I have recreated the issue and created PG-3116 to track the fix. We should have this resolved within the next two maintenance releases of ProGet.

Thanks,
Rich

Hi @aristo_4359,

Is this all rpm packages or just specific versions of a package? Can you share package names and version on the ones that will not delete?

@aristo_4359 said in RPM Bulk Edit Delete does not work:

Also a suggestion, when user delete package the page ideally stay on same page, instead redirecting to main feed on deleting single package and redirecting to first page when deleting using bulk edit

Thanks for the suggestion. The reason we redirect to the feed page after deleting a single package is because we don't know if the package will still exist (has other versions and/or is a remote package) in that feed. Although it is not trivial to check before we redirect, it could be added. I am going to add this to the list to discuss for ProGet 2026.

Thanks,
Rich

Hi @m-ruf_4197,

Sure thing! I have added ticket PG-3115 to track the feature. It should be released within the next couple of maintenance releases of ProGet.

Thanks,
Rich

Hi @caterina,

Good catch! We'll get that fix merged in.

Thanks,
Rich

Hi @windowsteam_8276,

Thanks for bringing this to our attention. We just pushed Otter 2025.1 that includes a fix, Ot-522, for that issue. Please upgrade to that version and let us know if that resolves the issue. Thanks!

Thanks,
Rich

Hi @inedo_1308,

I have just published a new CI build that should fix your issue. If you upgrade your Docker container to ProGet 25.0.8-ci.3, that should fix the problem with your feed usage instructions.

Thanks,
Rich

Hi @layfield_8963,

I'm having trouble recreating this error. I just stood up a clean install of ProGet 2025.7, created an asset directory, and uploaded a file to it. I then ran the command you sent and this is what I see:

pgutil.exe assets metadata set custom --path=test.txt --feed=test-import-data --key=test123 --value=12345
Setting test123 = 12345 on test.txt...
Metadata set.

Can you please navigate to Administration -> Software Info and copy and paste the contents of that here? If you feel more comfortable, you can email it to support@inedo.com with the subject [QA-2790] Database Information. If you email it, please let us know when you do so we can look for it in that mailbox. The only thing I can think of is that your database schema did not update properly on upgrade.

Thanks,
Rich

Hi @inedo_1308,

@inedo_1308 said in ProGet bug - Duplicate custom Feed Usage Instructions for Debian feeds:

Actually this feature (signed-by) is quite old. It just was badly documented for a long time (See this question) and therefore nobody used it.

Thanks for the additional details!

@inedo_1308 said in ProGet bug - Duplicate custom Feed Usage Instructions for Debian feeds:

I would appreciate that very much :-)

No problem, I'll reply back as soon I as I have a build ready.

Thanks,
Rich

Hi @layfield_8963,

Just to verify, is your instance using SQL Server or PostgreSQL? Also, can you please provide me the command you are using to recreate that issue? That will allow us to more quickly identify the issue.

Thanks,
Rich

Hi @inedo_1308,

I updated the name on that ticket. It will also cause other issues with other feed types as well. It is an issue with how it creates usage instructions that have the same name as other usage instructions (both built-in and custom). As part of that ticket, we will handle fixing the editing and deleting of instructions that were created incorrectly. The display issue will most likely need to be fixed by manually deleting the duplicates and recreating them (post fix).

I will also fix the Debian usage instructions as well. Since I'll be touching the code where the built-in instruction is stored, I was planning to just include them in that ticket, but I can create a new ticket for that as well. When we wrote our documentation for Debian, signed-by was not a feature yet. In the latest updates for the updated Debian feed, most customers were still using the legacy way for adding ProGet as a source. It has really only been in this latest major of apt that signed-by has worked consistently for us.

I plan to work on these early this week. If you want, I can provide you with a CI release as soon as these are ready if you want to test them early.

Thanks,
Rich

Hi @inedo_1308,

Thanks for sending this over to us. I created a ticket, PG-3069, to fix the exception with editing. I'll also get the feed usage instruction and our documentation updated with the signed by parameter.

Thanks,
Rich

Hi @jfullmer_7346,

Thanks for sending this over to us. This looks to be related to an issue with a stored procedure only used by this specific Asset metadata API. I have fixed this as part of PG-3062 and it will release this Friday in ProGet 2025.6.

Thanks,
Rich

Hi @caterina,

That looks to be an issue with the UI. Your feed policy will only ovewrite the specific license you marked as compliant and the remaining non-compliant licenses will still mark packages with those licenses as non-compliant. For example, any package AGPL-1.0 will still be non-compliant. On the second feed, it should be using the Global policy for that package. Can you share which feed features are enabled under the Feed Properties tab (Manage Feed in ProGet 2024) on the feed you promoted the package to?

Thanks,
Rich

Hi @kc_2466,

I just wanted to clarify Dan's comment a bit. The tz environment variable sets the timezone used in the container and time zone in the user config will only set the time zone to use in the UI, not the format of the date. Setting LC_TIME will change the locale within the Docker container and format it at the OS level, it doesn't look like that will be picked up in the .NET side of things. This is something I will need to discuss with the team internally. We have a team meeting on Monday (EST) of next week and I should have an update for you on the following Tuesday.

Thanks,
Rich

Hi @mhelp_5176,

When hosting via the Integrated Web Server, you will need to update the account the service is running as. As long as the GMSA is a db_owner on your database, then "Integrated Security=true;" in your connection string will use that account. As for installs through the InedoHub with "Integrated Security=true;" , it will use the account of the person running InedoHub when connecting to SQL Server during the install, so that account will need DBO on the ProGet database as well.

Thanks,
Rich

Hi @mwatt_5816,

Thanks for all of the detail. I have fixed the code, BM-3982, for this template and it will be released in the next maintenance of BuildMaster 2024.0.7 on Friday.

Thanks,
Rich

Hi @jfullmer_7346,

Thanks for the detailed recreation steps on this! I was able to recreate the issue and created a ticket, PG-3018, to track the fix. This is expected to be fixed in ProGet 2025.2 on Friday of this week.

Thanks,
Rich

Hi @petter-jacobsen_7171,

Just an update. It looks like I have found some issues with our policies. I have created tickets PG-3015 and PG-3016 to track the fix. These are expected to be released in ProGet 2025.2 at the end of the week.

Thanks,
Rich

Hi @stefan-hakansson_8938,

In ProGet 2024, we added support to enable enhanced database mode, which requires database owner, as an opt-in feature to prepare for ProGet 2025. Beginning in ProGet 2025, ProGet requires database owner on the ProGet database in SQL Server. Once you add DBO to your SQL user, this will unblock the upgrade to ProGet 2025. You can see more information in you [SQL Server & Inedo Products](In ProGet 2024, we added support to enable enhanced database mode
) documentation.

Thanks,
Rich

Hi @lukas-christel_6718,

Sorry for the delay on this. We just pushed an updated pgutil that will now skip over any invalid versions.

Thanks,
Rich

Hi @petter-jacobsen_7171,

I took a look through these and I have some more answers for you:

1. Looks like you added the package string to the license. You will need to navigate to Reporting & SCA -> Licenses -> manager license types & rules, then find that license, edit it, and remove the package string under the PUrls tab.

2. This looks to have been fixed in ProGet 2025.1 that released last night.

3. You can block a specific package on the Set Package Status page.

4. There does look to be an issue in policies, but I will need to dig into this further to determine exactly what the issue is. I will be looking into this more tomorrow.

5. I was unable to recreate this issue. It may have been fixed in 2025.1 or it may have been related to something else. Please note that if the package is in a connector, then the package will show in your feed once you delete it as a remote package.

6. This may be related to the issue in 4, I will update on this once i have dug in further.

7. Again, this looks to be related to an issue in policies.

8. I addressed this in my previous comment, but just wanted to call it out for completeness sake.

I should have an update tomorrow for you with more specifics around the blocking issues. Please let me know if you have any questions regarding my responses!

Thanks,
Rich

Hi @rel_0477,

I just happen to check right when this came in. Glad to hear it is working again! Was it the local cache? Cargo has a pretty aggressive cache for both good and bad packages.

Thanks,
Rich

Hi @rel_0477,

I apologize for not responding sooner. Can you please navigate to Manage Feed -> Storage & Retention and run the re-index operation? That should fix any packages that were pushed with the invalid JSON header.

Thanks,
Rich

Hi @darren-sloper_5044,

Great! Glad to hear you are up and running again!

Thanks,
Rich

Hi @petter-jacobsen_7171,

Thanks for submitting all this detail. I just wanted to let you know we are currently reviewing these items and will have an update later today.

I did want to make not that rollback is only supported when you upgrade from 2024 to 2025, then you will be able to downgrade back to 2024. With that said, that connector error may go away by simply restarting the ProGet services. If not, you can also try to uninstall 2024 and then reinstall it again and point to the existing database. That will force the schema update to rerun and should add back that missing stored proceedure.

Hi @kc_2466,

I'm having trouble recreating this issue. Are you using the built-in/unmodified publish packages task or did you create a custom one? If you created a custom one, please make sure all that all your options can be scoped to a feed (denoted by the "F").

Thanks,
Rich

Hi Darren,

We pushed a new installer last night and you should be able to use that to upgrade now.

Thanks,
Rich

Hi @darren-sloper_5044,

Thanks for all of the information! Installer issues take a bit to debug through, but we are looking into this now. Please hang tight and should have an update later today or early tomorrow morning on this.

Thanks,
Rich

Hi @matthias-reitinger_3646,

Good catch and thanks for sending over an example! I took a quick look and you are correct that bin was not included in the metadata for that package. I have created a ticket, PG-3000, to track the fix for this. Unfortunately it is too late to get this fixed in today's ProGet release, but it should be fixed in the next maintenance release of ProGet, 2024.39, which is expected in two weeks.

Thanks,
Rich