@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.

@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

Hi @koksime-yap_5909 , I'm afraid we can't provide much clearer guidance than that, as there are so many factors involved that make predicting performance basically impossible. For example, the feed types you're using, your CI server configuration, how often developers are rebuilding, etc. The article you found is actually what we send users who experience symptoms of server overload, to help understand where it comes from and how to prevent it. As the article mentions, the biggest bottleneck is network traffic during peak traffic - there's only so much that a single network card can handle, and scaling CPU/RAM doesn't really help. This is where load-balancing comes in. The main downside is complexity/cost, which is why a most customers start with a single instance. It can take quite a while for a tool like ProGet to be fully onboarded across teams, so performance problems likely won't happen at first. Hope that helps, let us know if you have any other questions! Thanks, Steve

Hi @stevedennis, Thanks for the update! I’m fine with waiting for the official release.

Hi @koksime-yap_5909, The command will recreate the user, restore administrative privileges, etc. It's safe to run - and you'll ultimately be left with a Admin/Admin user that you can log-in as. On ProGet 2025, the command is proget or proget.exe We should update the docs for sure Thanks, Steve

Hi @davi-morris_9177 , For multi-file packages like PyPI, the entire package (i.e. all the files) is promoted. This is the same in the UI as well. -- Dean

@yakobseval_2238 thanks for letting us know, I just updated it!

Hi @tayl7973_1825 , Thanks for the feedback; this is all a relatively new space, so we're in the process of building best practices / advice as well as tools to help teams solve these problems. Right now, based on your suggestion, it sounds like the workflow would require us to manually identify which applications depend on a vulnerable library, notify each owning team You are correct - the SCA Builds & Projects functionality is designed to "provide that link" between specific package versions and specific builds of applications. The builds are a moving target, as they may or may not be active/deployed. The "Project" in ProGet is not intended to the "source of truth" about the project itself, but be sort of sync'd with the truth (e.g. like an Application in BuildMaster). That's why there's a "stages timeline" for builds in PRoGet. hope it fits within their priorities, and then track remediation through individual tickets. Our advice here is to think of it more like, "advise them of the identified security risk and unavailability of the impacted library they are using". Ultimately it should be up to the team (their product owner) to evaluate the risk you identified and mitigate it. For example, TeamLunchDecider1000 can probably live with a security risk, but let the team decide. Once you've removed the library from ProGet, they can't use it anymore and it's "no longer your problem" to worry about or track through tickets. Ideally, we were hoping our package management system — since it already governs distribution and security controls — could act as that “one stop shop” to track and visualize which applications still rely on a vulnerable version along side it's assigned severity rating. ProGet already provides visibility into consumers through SCA, and you can already see how OSS Vulnerabilities impact builds. HOWEVER, our core advice here is to not try to establish your own in-house "vulnerability database" for in-house libraries your organization. Even large orgs (2000+ developers) won't do that. Instead, it's a simple binary decision: PULL or KEEP the library. If you PULL, then notify consumers it's unavailable going forward and let them decide how to mitigate. That approach is superior to OSS Vulnerability workflows, but it's obviously not possible for OSS library authors to do. Cheers, Steve

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 :)

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 for the quick response! I'm aware that I could have made sensitive information containing PID exposed to all users with access to the feed, but that is inappropriate within my organization. Best regards Nils Nilsson