Tested in 2025.15, working as expected now - Thank you!

Upgraded to version 25.0.15, and it's working. Thanks.

Hi @dubrsl_1715 I was sure that you must be interested in creating a product that would solve real tasks. Not really :) As a products company, we solve problems that a sufficient number of users would be willing to pay for and that aligns with our overall strategic vision. We also do User-Driven Development, which means we prioritize helping our existing users/customers solve problems instead of adapting the product for nonusers/evaluators like you guys. We don't consider packagist a competitor nor are we currently marketing users to switich; our solution is similar but not an analog. It requires a change to your workflow. The PHP/Composer market is already hyper-niche and I'm not convinced there's enough demand to develop a "versionless" package format (i.e. where a version number cannot be discovered in the manifest file or the package file name) format just for this particular use case (i.e. alternate workflow / simpler migration from packagist). None of the other feed types have this requirement, and it'd be nontrivial to modify our model to support this unique requirement. It would have downstream impacts to features like replication, disk-importing, reindexing, etc. Thanks, Alex

Hi @frank-benson_4606 , Thanks for clarifying, that makes sense. I'm afraid that ProGet does not "crawl" the parent artifacts for metadata; we had considered it, but it's rather challenging to do from an engineering standpoint, difficult to present crawler errors, and fairly uncommon. Thanks, Steve

Thanks! I think the restart of IIS App Pool might have helped. I don't see that failure anymore.

Hi Steve, I will look at an audit report to see if this can be used. Thanks, Frank

Hi @k-lis_1147, Sorry on the slow reply; we did not get a chance to investigate in last release, but it was on the list this week. That being said, it was also an easy fix (didn't anticipate it to be a copy/paste fix)-- and we'll get it via PG-3160 in this week's mainteancne release. Thanks, Steve

Things appear to be normal now, feed integrity checks didn't throw the errors after doing the thorough delete and then re-uploading those packages. Granted the powershell module is no longer getting updates to have parity with the version of winscp and that probably helps too.

@gdivis Too bad I already changed all my keys and updated a lot of Test-VM-Instances in an internal OpenStack. Would have been be MUCH less work. Oh well. Thanks anyway for the info -Fritz

Hi @m-lee_3921, When specifying a package source, the package must be in the same feed; you could specify it using a URL however. { "virtualPath": "common/logo/logo.png", "source": { "url": "http://proget/endpoints/customer-assets/content/ast-logo.png" } Good point on the documentation; download-vpack is for the .vpack file only (i.e. manifest). I'll update it -- Dean

@uel_2013 (I deleted my previous reply since I learned a few more details from a team member who talked with you already) Given your team size, you'd definitely be better off upgrading (rethinking) your CI/CD processes when switching over to BuildMaster. As some users have told us, the Octopus Deploy way is like "trying to apply the SVN mindset in a Git world". The main benefit to a small team is that it's a simplification/consolidation of build- and deployment tools, while also giving you a powerful platform and process. We're working on "codifying" this in an upcoming guide called Lean Platforms: Engineering & Orchestration. You could likely get BuildMaster to work in a similar way (i.e. a "deployment script runner"), but you'll be "fighting against the current" and you would be missing out nearly all of the benefits. For example, we have different ways of handling multi-tenancy (e.g. depending on if you do quasi-custom software) and the Git and Issue-tracking integration will make a huge difference in your internal processes. I'd suggest taking a quick tutorial of the software (you can freely download it), and see how far you can get with setting a basic application from scratch. That should help you see the differences and how the concepts maps. There are a lot of similar ideas, but like Git and SVN, there are differences that don't translate very well. -- Dean

Hi @rick-kramer_9238 , It looks like you're using ProGet 2023? That functionality was relatively new in that version and there is very possibly some kind of bug linking the two together. We've since made some big improvements to SCA/compliance, so I would recommend upgrading. Many of the changes were in ProGet 2024: https://docs.inedo.com/docs/proget-upgrade-2024#new-features-in-proget-2024 -- Dean

@curtis-denotter_1361 Were you able to resolve this? If so, what was the root cause?

@rick-kramer_9238 I added the default source as the nuget feed instead of https://proget.corp.com. Seems to be working now.

@dean-houston said in Published timestamp resets after pulling remote npm packages: "Admin > Advanced Settings > Use Connector Publish Date" Thanks a lot for your fast reply, changing that setting works like a charm.

Hey Steve, thank you very much. That sounds like a valid explanation. Let me try to work this out with the third party then and see if I can get them to look into their build process. I thought about repackaging and looked into the ar parts too, but since this then needs to be done for every version coming out, I would rather not be an additional step in between and have it working out of the box. ;) Many thanks, Frank

@rhessinger Well, after restarting with the 2025.14 image that I pulled this morning, now the warning is gone. Guess this was some outlier then ... Thanks -Fritz

Hi @yaakov-smith_7984 , This behavior is expected and by design. "Deprecation" and "Unlisted" are server-side metadata (i.e. stored in the remote repository, not the package itself), and once a package is brought into to a different server (i.e. ProGet), it's "disconnected" from the other server. That being said, there is a feature in ProGet that can routinely "sync" this server-side metadata: https://docs.inedo.com/docs/proget/sca/howto-deprecated-package-alerts https://docs.inedo.com/docs/proget/sca/policies#oss-metadata-updating-caching This feature obviously comes with some performance costs, though you'd really have to enable it to see if that has any impact on operation. Another approach is to use a retention policy that deletes cached packages older than 90 days. Thanks, Steve

@dean-houston, thanks for fixing that bug and detailed response to dependencies.

Hi @koksime-yap_5909 , Data deduplication is an operating-level system function. On Windows, there's the Data Deduplication Feature. There are more options for Linux, but ZFS Deduplication is pretty popular. -- Dean