Hi @jonathan-simmonds_0798, Thanks for the suggestion! This has been a long-standing wish-list item, but it's deceptively complicated. The "current idea" is a feature called "raft analysis" that will create a list of all raft items that depend on other raft items. For example, a pipeline that references a script. Or, a script that calls a module, and so on. It could also detect warnings/errors and report them. Creating this list often involves opening thousands of files and "parsing" them, which is not a trivial operation... but we're only talking "a few minutes" in most cases. However, the main challenges arise with invalidating this list (many edits will cause that to happen), and then communicating the status of the rebuild to users. I'll add a note to our BuildMaster 2026 roadmap though and see if we can explore it again; the current focus is boring..... modernization (PostgreSQL). That said, you probably noticed it but.... you should be able to see if a particular pipeline has an error (like a missing script) on the piepline overview page. Not as nice. Thanks, Alana

Hi @parthu-reddy , At this time, we don't have a disk cleanup procedure for local storage like this; we may add it in the future, but for the time being you can just delete them. The LocalStorage folder is ephemeral -- not quite "temp" storage, but the contents can be deleted. They will just be recreated next time it's needed. Thanks, Alana

Thanks, that worked! We've had problems with this repo before as directory browsing isn't allowed due to the fact it's hosted on S3, so it breaks some software if you just put in the folder path. I guess ProGet is properly just appending the usual location of the repodata file instead of requiring the ability to browse the root folder.

Hi @koe , This is definitely a problem that you can solve with BuildMaster, but before giving any kind of technical guidance, I'd like to understand the business processes. On first glance, this sounds like one of two scenarios: Quasi-custom Software, where you create a customized build of a software application (perhaps bundled with their plugins, etc) User-driven Deployments, where you maintain a single application but deploy a new version of that application based on user requirements (new feature they requested, bug fix, etc) Are either of those close? Whatever the case, can you describe the decision-making process or rationale that goes into "deploy a software release to either all production systems, all test systems or just a single one out of all these systems?" Are there different types of releases (e.g. a "patch" release of an old version)? Or is everyone "forward only, latest version"? BuildMaster is, of course, an automation platform - but more importantly, it's about modeling process and visualization. And when it comes to process, consistency is key - even when there are variations. We don't believe a decision like above is "arbitrary, and based on the whims of an application director", but there's probably some rationale that goes into it. So, with BuildMaster, our goal is to help get everyone on the same page about which process to follow for different releases. Anyway, how you model this will have a big impact down the line. Cheers, Alana

Hi @Nils-Nilsson , Good news - this is actually on our ProGet 2026 roadmap. The general idea is to "reuse" Feed Groups -- I guess we'd call them "Feed & Project Groups" or something? Anyway, the projects would be grouped in the UI similarly, and you could scope project-based permissions to a group. We will try to get it as a preview feature in the coming weeks, assuming it can be done in low risk. It seems like this would be the case. Cheers, Alana

I have downloaded ProGet 2025.0.19 and was able to successfully change the location for that last setting. Thanks.

Hi @geraldizo_0690 , Thanks for the report! Sometimes bug fixes are a single character like this ... [image: 1769504251057-1c7d2a43-f6ca-41b0-9853-65cdea7cb5b7-image.png] It'll be be in the next maintenance release via PG-3205 :) Cheers, Alana

Hi, our Proget instance was updated to 2025.19 (Build 14) and the above described issue disappered. Excellent! Thanks!

Hi @davidroberts63 and @mikael , Thanks for the insight and ideas! I'm surprised to hear that a "proxied" Terraform Provider Registry wouldn't be a security concern; it seems like a great vector for a trojan-horse provider reference (say aws-core) to be snuck into some proxied module dependency and auto-downloaded and run? Of course I know nothing about how Terraform actually works... or if that attack would be possible. Realistically, someone would probably catch/report it shortly after discovery... but "proxying executables from community repositories" raises a big red flag for me. Anyway, it'd be a lot of effort to build this into ProGet and I don't think we can really offer any value over a specialized basic free/open source tool that hosts these providers. Ultimately it'd be like an Asset directory, but slightly more restrictive and with an even worse UI ;) I think if we're going to consider specialized feeds to host "non-package" files, we should probably start with like Git LFS... then Git repositories, and so on. Anyway keep us posted on the journey; I'm sure this is one of those things you could built-out in an Asset Directory using pgutil and a ChatGPT-generated script to generate the index file. Cheers, Alex

Thank you. Does it mean that I must stay with the SQL server version and do not migrate to the one with PostGres.

For now we try to use a workaround - It would be really helpful for us if this would be implemented into the code in the future.

So I succeeded this time, I changed the montpoint to /data and created the subdirectories: mkdir -p /data/proget/proget-backups mkdir -p /data/proget/proget-database mkdir -p /data/proget/proget-packages Set correct permissions on the folders (same permissions as on the./proget-* folders) chmod 700 /data/proget/proget-database/ chmod 755 /data/proget/proget-backups/ chmod 755 /data/proget/proget-packages/ Set ownership chown 101:root /data/proget/proget-database/ chown root:root /data/proget/proget-backups/ chown root:root /data/proget/proget-packages/ Set correct SELinux context semanage fcontext -a -t svirt_sandbox_file_t "/data/proget(/.*)?" restorecon -Rv /data/proget Stop- and remove proget (I had a sapshot of the server as backup) docker stop proget docker rm proget rsync data to new directory rsync -avh ./proget-packages/ /data/proget/proget-packages/ rsync -avh ./proget-database/ /data/proget/proget-database/ rsync -avh ./proget-backups/ /data/proget/proget-backups/ Then install with (:z added for SELInux) docker run -d --name=proget --restart=unless-stopped \ -v /data/proget/proget-packages:/var/proget/packages:z \ -v /data/proget/proget-database:/var/proget/database:z \ -v /data/proget/proget-backups:/var/proget/backups:z \ -p 8624:80 \ proget.inedo.com/productimages/inedo/proget:25.0.18 last, remove the old directories in root home folder after ensuring everything is OK. cd ~ rm -rf ./proget-packages ./proget-database ./proget-backups Now it works as expected. i don't know what I did wrong last time, but now proget isn't filling up the root directory anymore. probably obvious for everyone used to docker, but wasn't for me :)

Hey Alana, No worries. I have a similar issue with an Ansible deployment in Kubernetes with permissions. So I have a special file share now for images that don't support changing the user/group that processes run as. Basically, the file share exposed and consumed by the image is configured (when using squashing) to have certain permissions. And we can make docker containers or Kubernetes deployments compatible by specifying the securityContext to tell it when user & group to run the pod as, or some containers allow specifying a user ID and group ID as environment variables. This is just to control the linux permissions for folder/file access. Somewhere in the image setup, there's configuration forcing it to access /var/proget/database as the user "postgres" and with the group "root", and it tries changing permissions on that folder at some point. If the image supported the securityContext or the user/group ID environment variables, it would run as those specified permissions instead - but - your image would need to be able to run as those permissions, and it would probably take some work to get the image reconfigured to allow that, and to do testing. For now, it works. It would take some evaluation to see if your image would support changing the user/group away from the current postgres/root.

Yes , it is indeed npm packages, yes I was using /packages. Though when traying to search within /feed it was also strange as it seems to ignore @ . Both are okay for now. Just put it somewhere in the improvement list, I understand there is some limitation to it, encoding, filter etc and trying to do universal search across different type.

Hi @jw , We added "auto-publish Inedo.ProGet" to our internal tracking list -- and in theory it will be done in the next week or so. I think we meant to do that earlier but it just fell off the list. Thanks for pointing that out - please don't hesitate to bug us if you don't see it published next time :) Thanks, Alana

Hi @jolaka9284_9459, We have pushed some improvements in ProGet 2025.18. These improvements include: Improved connector metadata caching (may require an increase in the number of cached requests) Improved index generation code A new Feed management setting for Dependency Resolution Standard Resolution, check in ProGet if that dependency exists Force all dependencies through ProGet Always use this feed unless Registry is specified In your case, since you are using ProGet as the mirror, I would suggest forcing all dependencies through ProGet, which can be configured on Feed -> Manage Feed. Thanks, Rich

Hi @wechselberg-nisboerge_3629, In ProGet, the maven metadata files (xml, hash) are indeed generated upon request. The output is deterministic, based on the artifacts in storage and (if relevant) in the remote repository (i.e. connectors). So, if you're seeing it changed, it's because an artifact was uploaded/etc. One thing to note -- you cannot upload a metadata file or hash file. Well, you can try (and maven tries) to PUT the file, but the stream is always ignored or "written to /dev/null" as they say. We've seen some maven workflows/plugins that attempt to modify/append to this metadata file and re-upload it with changes. Thanks, Alana

Hi @atripp, thanks for the explanation. I can understand that you are not willing/able to change this behavior. Now I will check if it is possible for us to modify the underlying wget call to allow downloading of the files from ProGet. Best regards

Thank you

@rhessinger While that kind of makes sense, I dont think that is the issue. In the past, I've imported projects from production TC servers to the test server. Thinking this may have been part of the problem, I instead created a brand new project on the test server called "WebProjects_SessionManagement". After creating the project, I created the build config "WebProjects_SessionManagement_BuildChanges". I created 3 dummy steps and then ran those builds 3 times. After that was done, I created a new Application in BuildMaster. When I went to import the 3 builds I created, it resulted in the same behavior that I saw before. When I check the API (/app/rest/projects/WebProjects_SessionManagement?fields=buildTypes(buildType)), I get this for projects: <project> <buildTypes> <buildType id="WebProjects_SessionManagement_BuildChanges" name="BuildChanges" projectName="Web Projects / Session Management" projectId="WebProjects_SessionManagement" href="/app/rest/buildTypes/id:WebProjects_SessionManagement_BuildChanges" webUrl="http://10.0.14.200:8111/buildConfiguration/WebProjects_SessionManagement_BuildChanges?mode=builds"/> </buildTypes> </project> And then when I check the builds for this project (/app/rest/builds?locator=defaultFilter:false,project:WebProjects_SessionManagement&fields=build(id,number,status,state,webUrl,startDate,buildTypeId)), I get this: <builds> <build id="10342" buildTypeId="WebProjects_SessionManagement_BuildChanges" number="26.20.0117.3" status="SUCCESS" state="finished" webUrl="http://10.0.14.200:8111/buildConfiguration/WebProjects_SessionManagement_BuildChanges/10342"> <startDate>20260117T214753-0500</startDate> </build> <build id="10341" buildTypeId="WebProjects_SessionManagement_BuildChanges" number="25.20.1317.2" status="SUCCESS" state="finished" webUrl="http://10.0.14.200:8111/buildConfiguration/WebProjects_SessionManagement_BuildChanges/10341"> <startDate>20260117T214729-0500</startDate> </build> <build id="10340" buildTypeId="WebProjects_SessionManagement_BuildChanges" number="25.20.1317.1" status="SUCCESS" state="finished" webUrl="http://10.0.14.200:8111/buildConfiguration/WebProjects_SessionManagement_BuildChanges/10340"> <startDate>20260117T214719-0500</startDate> </build> </builds> and yet, no builds in the dropdown in BuildMaster