Posts made by rhessinger

Hi @kquinn_2909

That is why you are not seeing the builds. That build types API is returning the Id as WebProjectsReplicatorBuildOnChange, where the builds API is returning WebProjects_Replicator_BuildOnChange as the Id. Are you using any sort of shared build type?

Thanks,
Rich

Hi @koksime-yap_5909,

No problem! Happy to help!

Thanks,
Rich

Hi @kquinn_2909,

I'm working to recreate this issue, but I'm struggling to recreate it. Would you be able to send us the results of the following API?

app/rest/projects/WebProjects_Replicator?fields=buildTypes(buildType)

The thought I currently have is that the Build Type list is returning something different that is filtering out those builds (https://github.com/Inedo/inedox-teamcity/blob/7d447a5f4f3c3e38c98012c65e9db40afec224b6/TeamCity/InedoExtension/TeamCityClient.cs#L84)

Thanks,
Rich

Hi @koksime-yap_5909,

After looking into this further, although we can fix the import to handle the images without a media type, it will still be broken when you attempt to pull those images using the Docker client. This is because ProGet will only send the manifest as it is stored in ProGet, where Nexus will manipulate it to match the accept headers of the client. Since it is only returning the manifest as it is stored, the media type will be null which will cause the Docker client to fail with a missing or empty Content-Type header.

Since we cannot assume what the mediaType should be, I think it would be better to resolve those prior to importing into ProGet. The nice thing is you can use the import logs to identify what images are missing the media type. You can run the import multiple times and it will only import the missing images and layers.

Thanks,
Rich

Hi @koksime-yap_5909,

I apologize for the delay. This is next on my list to review and I will have an update for you on Monday.

Thanks,
Rich

Hi @udi-moshe_0021,

Would you be able to provide the Installation logs from a failed install? You can get them by rerunning the Offline installer and then clicking on the Logs tab.

The other ting I would try doing is try running ProGet from the command line and then sharing the output with us. That may tells us any startup issues the application has. To do that, open a command prompt, navigate to the install directory (cd "C:\Program Files\ProGet\Service"), and then run proget.exe run. Could you share the output from that?

Thanks,
Rich

Hi @henderkes,

No problem! Both these issues are expected to be fixed in this Friday's release of ProGet 2025.18.

Thanks,
Rich

Hi @henderkes,

So we have identified the issue. When it comes to your packages, there where two issues that were preventing them from being updated and installed.

1. The packages you provided to me are unsigned. According to the APK documentation, that is not supported. In reality, that is a case that they support and have supported for some time. So we have a ticket, PG-3192, to correct the checksum generation for unsigned packages.
2. When a checksum is not generated, ProGet was inserting the hash of the package instead, which would cause the index to fail.
   • In older versions of APK tools V2, this would fail the install of that package, but show you the all packages in the index.
   • In newer versions of APK Tools V2, it will stop processing once a package with a bad checksum is shown. Which is why it looked like only one package existed in the feed. Installing these packages will most likely fail with a checksum error.
   • In APK Tools v3, it errors on apk update and these packages cannot be installed at all.

We are going to be adding the checksum verification to the Feed integrity checks and a way to regenerate the checksums in ticket PG-3193. That should resolve all these issues for you. That also explains why my test cases worked fine, because most public index packages are signed packages.

Thanks,
Rich

Hi @udi-moshe_0021,

Our Windows test servers are a vanilla install of Server Standard (we test against a few different versions) with nothing but the defaults configured and the latest Microsoft updates applied. It is possible that specifying a different user could cause it. Just make sure that the user you specified has read, write, and modify permissions to the Config File Directory (typically C:\ProgramData\Inedo). Upon first start of the ProGet Service, it will create and setup the embedded database and update the ProGet.config file. Based on error, that looks to be where it is failing. I wonder if you are missing the modify permission on that directory and it is failing to update the ProGet.config file.

Thanks,
Rich

Thanks,
Rich

Hi @henderkes,

Sorry for the delay on this. Right now, there looks to be a couple issues I'm working through with this. I should have an update for you on Friday. I believe I have identified the issues, but I'm trying to confirm some things based on your APK packages. Just to confirm, the packages you shared are APK Tools V2 packages correct?

Thanks,
Rich

Hi @koksime-yap_5909,

Thanks for sharing the steps. I'm going to attempt to reproduce this and I'll let you know what i find!

Thanks,
Rich

Hi @udi-moshe_0021,

I just ran some tests with both 2025.16 and 2025.17 using the embedded database on a clean install of Windows Server 2022 and everything installed and ran as expected. The only other thing I could think of could be a permissions issue. What account did you have ProGet service running as?

Thanks,
Rich

Hi @koksime-yap_5909,

Ah ok. It make sense that we would not be able to pull those based on the accept headers. How many images do you have without a media type? Are these mostly old images or are there new ones missing this as well? Do you know how to recreate an image in Nexus without a media type?

Thanks,
Rich

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