Hi @kc_2466 ,
Thanks for the report; we'll get this fixed in the next maintenance release (this week) via PG-3064
Thanks,
Steve
Hi @kc_2466 ,
Thanks for the report; we'll get this fixed in the next maintenance release (this week) via PG-3064
Thanks,
Steve
That makes perfect sense; when package caching is enabled, the package files are added to the feed and stored on disk. When it's not enabled, they are simply streamed from the server.
Something is interfering with your disk storage that is deleting (quarantining) files on disk. You will need to follow the troubleshooting I identified above - it's probably a security tool.
Suggest using AWS Lightsail to get a test box in an environment you can control.
Thanks,
Steve
Hi Marc,
I'm not sure what you mean by 2024.8-r1 but the -ci.x and -rc.x images are prerelease versions. Sometimes they are the same as the release versions, sometimes they aren't.
I wouldn't use prerelease versions unless we suggest them to you for a specific issue you're facing.
-- Dean
Hi @v-makkenze_6348 ,
You can use a ProGet Trial Key or if this is just a quick temporary instance, just use your existing license key to try it out.
Thanks,
Steve
Thanks @imm0rtalsupp0rt, this is exactly what I was looking for -- I'd like to be clear what's wrong though.
You're saying the $.data[].versions[] array only contains the latest version, and not all the versions?
Hi @carsten_1879 , just to give another update.
The issue appears to be localized to your ADO Server, perhaps it's the version or locale. The authentication header doesn't seem to make any difference.
Whatever the case is, the library we use, libgit2, simply cannot clone from it -- for whatever reason your ADOS is returning a 400 with some German error message when doing what should be a totally fine request. We did not test with git.exe.
Our new, proprietary library also does not work, but for a different reason - it looks like ADOS is using an ancient format (like from 2010??) for one of the reposes, so we don't support that yet. At least we think.
We'll need too spend a bit more time researching this, so it'll get pushed into the following weeks.
Thanks,
Steve
@steviecoaster @imm0rtalsupp0rt in the screenshot above it's not clear what API is being used, what queries are being made, and what's expected -- if you could provide us with that, we could troubleshoot this very quickly
@stefan-hakansson_8938 as you noticed, ProGet's Debian connectors are not currently designed to handle the gigantic, operating-system mirrors very well. This is because they are always refreshed "on demand" - which is what you want for CI/CD workflows.
It's not great for public repository mirroring, however. In Q4 or later, we will explore adding an option to do periodic updates.
@v-makkenze_6348 thanks, unfortunately I wasn't able to reproduce it
Can you try a manual import by going to Reporting & SCA > Projects & Builds > Import SBOM > paste in your SBOM?
If that gives an error, can you also try to edit application name/version in the XML before pasting? Fox example, change it to:
<component type="application">
<name>MyTestProject</name>
<version>25.3.85.1</version>
</component>
That will create it as a new project/build.
Just trying to figure where the issue might be.
Thanks,
Steve
@carsten_1879 thanks for the update
We were able to reproduce this using your credentials, and It's definitely an "error reporting an error" on Linux. On Windows it's clearer ("too many redirects or authentication replays").
We do not test on ADO Server, but we quite a few customers users with it - who knows why it works for them but not you. Anyway, please bear with us as we figure it out.
Hi @imm0rtalsupp0rt ,
We don't know choco search is doing behind the scenes with regards to API calls, but I think it's using the V2 ODATA API. That gets pretty complex and we don't have enough information to work on yet - and trying to set up a reproduction case is quite the endeavor.
Could you provide a very basic reproduction, perhaps with a dummy package or two, using only the API calls? If you use something like Fiddler you can see the underlying API calls
Thanks,
Steve
@erich_1530 in the ProGet software, you will see a "License REquired" error message. if you click on the "Request License Key" you can get a Free or Trial key from within ProGet. Or you can go to my.inedo.com and request a key from there if your server does not have internet access
@carsten_1879 excellent, thanks! Please give us a little time to review this.
We will also test it with the new Git library, which is available in buildmaster:24.0.8-ci.9 container image -- you have to go to Admin > Advanced Settings and enable it.
If you get a chance to try it yourself, please let us know. We are currently testing it ourselves on our main server.
Hi @james-woods_8996 ,
No problem using ProGet 2025 Docker Image with SQL Server - it works exactly as it did in ProGet 2024.
We will continue to support SQL Server in the through at least ProGet 2026.
Thanks,
Steve
@phopkins_6694 perfect, just what I was looking for
I was able to reproduce this - searches via the NuGet API (which connectors use) will consider tags, while local searches seem to only be looking at names.
I'm not sure how long this has been the case, but we'll try to get it fixed soon. Unfortunately it's not a trivial fix, hopefully we'll do it via PG-3046, likely in the July 18 maintenance release.
Thanks,
Steve
Hi @erich_1530,
Nice idea for the docs, I just updated.
It looks like the software was successfully installed.
What does the "Services" tab show? There will be a "Logs" tab that should provide you with the logs.
I would try to uninstall and then reinstall using the Inedo Hub. Also reboot just to see if that works.
Thanks,
Steve
Hi @caterina ,
Multiple policies will "stack" and are evaluated in order from Global > Shared > Feed. It can get pretty tricky, so I would use the "Re-analyze" feature on a package - this will print out some detailed analysis logs that show you exactly what rules are being followed.
The "Policies and Blocking" view under the Manage Feed pages will try to combine these a single view, but you may find that using Admin > Policies is helpful... it only shows one policy at a time, and does not combine them.
To add to the complexity, compliance results are cached on the "list packages view" -- so that's why it's important to do that renalyze function to make sure you're looking at the right results.
The caching doesn't last long (few minutes), but it makes debugging a challenge/
Thanks,
Steve
Hi @carsten_1879 ,
Huh weird... so GitHub works, but your ADO Server doesn't. I bet it's related to some kind of TLS or something?? We may be able to see it with Wireshark or something.
Anyway if you can give provide us with credentials that would be great. We can then test on our new GitLibrary and see if it works.... maybe the solution is just to get you that instead.
Just email the info to support at inedo dot com, and include [QA-2678] in the subject line. But let us know when you send it, because we don't monitor that box.
Thanks,
Steve
Hi @erich_1530 ,
I'm not really familiar with how installation issues are reported with Chocolatey, but if you don't see a INEDOPROGETSVC service, then I think there was some kind of installation issue.
I would start by using the Inedo Hub instead of silent/automated installation. Once successfully installed, there will be a "Launch" button - it just loads https://localhost:8624, which is the default port for ProGet. Once you do that, the software will walk you through configuring HTTPS, which you can do later.
You may or may not be able to access the software by going to http://your-server-name:8624 due to firewall or network restrictions. But that's handled outside of ProGet.
Best,
Steve
@v-makkenze_6348 can you email it to support at inedo dot com with [QA-2775] in the subject, and let us know when you sent it? We can find it then
Thanks
Hi @carsten_1879,
The mystery continues.
The strange thing here is when adding a new connection to azure devops and entering the instance url, username and personal access token, i am able to browse the projects and repositories in the buildmaster setup dialog.
Behind the scenes, the project/repository browsing are handled using the ADO API, which is called from .NET code, which eventually uses the openssl library installed on the operating system. Clearly, this is working... and I think your credentials, etc. are fine.
HOWEVER, the cloning is handled using a totally different library called libgit2. It uses libssl behind the scenes, and clearly this is not working.
Unfortunately, libgit2/libssl are a lot less forgiving with SSL issues than .NET and a lot more cryptic. So it's possible that the "could not open libssl" isn't even the actual error message.
The real mystery here is why is this not working for you but it works fine for us? Especially since we're both using the same container image?
One guess I have at this time is a proxy server is "reencoding" the SSL stream using an algorithm libssl doesn't understand? And then, this error is thrown? Or, perhaps it's a locale thing? Just some wild guesses.
Could you try this with like, GitHub perhaps? Or maybe you could try this on a public server that we could access, like a Amazon LightSail server?
FYI - on our end, we have written our own Git library from scratch using .NET that will not have these problems. It's almost ready.
Thanks,
Steve
Hi @phopkins_6694 ,
Probably not - the search in Chocolatey and ProGet UI will be different, and that's not something reasonably addressable. So let's start the issues you're having with ProGet UI search.
Thanks,
Steve
Hi @phopkins_6694,
I'm afraid not; the Chocolatey client and ProGet UI perform different search functions so there's not much we do with that information.
If you can provide a very specific reproduction case, we can investigate:
If you share the nuspec of the package you uploaded and your search terms, we can try to reproduce the case and see if we can reproduce. Then we can explain or fix the behavior.
Thanks,
Steve
Hi @v-makkenze_6348 ,
The SCA Import "Nullable object must have a value" is likely coming from data in your SBOM XML. It's likely unrelated to Postgres, and more related to the library upgrades. Can you share with us the SBOM document you are uploading?
The Connect errors are unrelated to your switch. Based on the stack trace, it looks like you have a no-longer-supported setting called auding proxying enabled, and npmjs.org is timing out while making that request. You should disable that by navigating to the npm feed's "Manage Feed" page and configuring npm audit setting to Enabled or Disabled.
Thanks,
Steve
Hi @phopkins_6694,
If you've upgraded, then the tags should now be displayed on the Metadata tab of the package.
When doing a search in the ProGet UI for NuGet (and Choco/PowerShell) packages, the Name, Description, and Tags are considered. However, the ordering may not be what you expect, especially if your tags are common words common in many names/descriptions.
Thanks,
Steve
Hi @carsten_1879,
The underlying error message ("could not open libssl") is related to your specific environment; it's an error occurring at the operating-system level where it's failing to load a dependency that is already installed (in Docker/Linux version).
We made a change in BuildMaster 2024.06 that may have had an impact, but since you tried 2024.05 we can rule that change out.
So at this point, we need to try to figure out why it isn't working for other users (including us during testing).
Can you tell us a bit about your environment? Like the host? K8 vs Docker? Do you have any special security software running?
Thanks,
Steve
@stefan-hakansson_8938 thanks for confirming, I see what's happening
Debian feeds do not use metadata caching (they have a local index file instead), so it's not settable and is always displayed as "disabled" in the ProGet UI. If you were to go to the connector page, you won't be able to set it. HOWEVER, it's settable using the API.
I cannot reproduce this in ProGet 2025 - the value is set and displayed correctly, as expected.
Both the UI and API use the same code to retreive/load information from the database, and there is no data caching here, so I'm thinking there might be some other issue (looking at wrong instance, looking at wrong connector, etc).
Thanks,
Steve
There's no point in verifying a fingerprint (i.e. hash) for content from a trusted HTTPS source. In the olden days (before "SSL Everywhere" with unreliable downloads and questionable mirrors), it was an important way to validate integrity... but there's no sense to it today.
If one were to "compromise" a trusted HTTPS source and tamper with content (signing keys, packages, etc), then they could just as easily tamper with hashes provided by the source. So you can simply just accept whatever key ProGet provides you -- no need to "think twice" about it.
Hashes can help with troubleshooting corrupted files... but with network speeds so fast, you can just redownload it when file sizes don't match.
Hope that helps,
Steve
@michal-roszak_0767 I think this is a similar question to your post in another thread, so I'll just quote my response from there:
@stevedennis said in services.gradle.org proxy:
Hi @michal-roszak_0767 ,
That looks like it's just a "web page" with a bunch of links to files?
ProGet does not support connecting to "web pages" and we have no plans to add that feature. There's simply no API to use, which users could never be able to "see" the files in ProGet until after they've been downloaded -- and the lack of metadata also creates all sorts of other complexities.
However, you can create an asset directory to store "generic" files. It's basically a web-based file system: https://docs.inedo.com/docs/proget/asset-directories-file-storage/what-is-an-asset-directory
Thanks,
Steve
I think that @dan-brown_0128 is on the right track - if you can parse the "web page" and know what links reference files you want, then you could then follow those links, download the files, and upload those files to an asset directory
Not sure if you're able to share the script @dan-brown_0128 but if not, it'd probably be "relatively easy" to get ChatGPT to hep with or something
Hi @michal-roszak_0767 ,
That looks like it's just a "web page" with a bunch of links to files?
ProGet does not support connecting to "web pages" and we have no plans to add that feature. There's simply no API to use, which users could never be able to "see" the files in ProGet until after they've been downloaded -- and the lack of metadata also creates all sorts of other complexities.
However, you can create an asset directory to store "generic" files. It's basically a web-based file system: https://docs.inedo.com/docs/proget/asset-directories-file-storage/what-is-an-asset-directory
Thanks,
Steve
@mmaharjan_0067 we'll see how we can improve this while we work on PG-3034
@mmaharjan_0067 thanks for sharing that
I misunderstood the remove command -- I didn't realize that was deleting from the feed, and just assumed it was removing from the local project or something.
I don't see any code for DELETE in the feed, so we would have to add that. No idea how easy that is going to be, but we'll try doing it at same time with the UI improvements. You can track via PG-3035.
Thanks,
steve
Hi @mmaharjan_0067 ,
This is definitely some kind of UI regression; we did a lot of code-cleanup / refactoring on the front-end pages. We'll get this fixed via PG-3034 in an upcoming maintenance release (targeting next week's 2025.4).
Thanks,
Steve
@p-pelinski_1371 @pbe_9047 thanks for confirming that!
We will get this fixed via PG-3031 in the next maintenance release. You are also welcome to try the proget:25.0.3-ci.3 container image, which is building now.
Hi @mmaharjan_0067,
I think we can call this a "known limitation" now that you've discovered it ;)
It's a bit tricky to set up a conan debug/testing environment, so to advance this further instead of putting off another few days.... do you mind trying to run the command with --verbose and share the output? How about without the -p command?
I'm just trying to see what URLs the conan client is trying to call, and make a guess for how we can address it.
Thanks,
Steve
SSL/HTTPS is all handled at the operating-system level.
When there are SSL/HTTPS issues then you will see some kind of OS-level error in ProGet. You can see what these are like by connecting to one of the "bad" options at https://badssl.com/ - the connection will be refused.
Thanks,
Steve
Hi @pbe_9047 ,
Can you share what you see on Admin > Database Overview page?
Also Admin > System Inforamtion?
Thanks,
STeve
ProGet relies on SSL/HTTPS, so instead of connecting to http://archive.ubuntu.com/ubuntu/ you should use https://archive.ubuntu.com/ubuntu/
I just updated the docs you found to use https instead of http - thanks for pointing that out.
Thanks,
Steve
That's the intended/expected behavior of repackage. The use case is CI/CD workflows, so you would do something like:
w.x.y-ci.zw.x.y-rc.zw.x.yRetention policies would then clear out old -ci and -rc packages.
I believe that display bug has been fixed in ProGet 2025; I remember seeing it listed as a bug discovered during testing. But in any case, it's in the package history as you can see.
Hi @mmaharjan_0067,
I can't easily create and populate a Conan feed.... but if I remember correctly, I think that everything is stored as blob files? Like hashes for names, with nothing useful?
Do you see anything under the package store (i.e. on disk) that might be useful to display?
Thanks,
Steve
Hi @kc_2466,
Prerelease segments are sorted numerically, so 1.0.0-ci.10 > 1.0.0-ci.2 as you would expect.
If most builds are never released to production (a common CI/CD scenario), this is a great approach.
Thanks,
Steve
Hi @mmaharjan_0067,
Can you clarify this one a bit? I'm not picturing what you're requesting and I'm also not sure if there's much we can show.
I do know that Conon feeds are a bit limited due to the limitations of the Conan Server API / protocol. If you see other feed types / products handle this differently, let us know.
Thanks,
Steve
Hi @mmaharjan_0067,
This is not a trivial request and would require database changes, new API endpoints, and of course pgutil changes. We will put it on our ProGet 2026 roadmap for future consideration -- hopefully some other users will chime in!
Thanks,
Steve
Hi @kc_2466,
SemVer build numbers are really weird -- they are not intended to make a version unique. In other words, 3.4.1+1 and 3.4.1+2 are considered equal, and thus overwrite them.
As for 4-part numbers, that is most definitely a validation bug - Universal Packages use SemVer, and 4-part versions are invalid. Now that we know about it, we will likely fix it - so don't use it.
I'm not totally sure what you're trying to accomplish, but the best CI/CD workflow for builds and releases is to use prerelease/repackaging:
https://docs.inedo.com/docs/proget/packages/repackaging
If, for whatever reason, your package needs a version number that SemVer does not support, you can do something like yz = y*100000 + z*100. For example, 4.2.1.5 becomes 4.2.100500
Thanks,
Steve
I'm afraid we simply can't reproduce this. Here is what we do:
/feeds/marvin/org.hamcrest/hamcrest-core/1.3All files will show up in the list because the index file is downloaded; if the index file was not downloaded, only the pom file will show. But the behavior is the same either way.
The artifacts download with no issue, as expected:
curl http://localhost:8624/maven2/marvin/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar
curl http://localhost:8624/maven2/marvin/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.pom
They download in any order just fine, and I can delete them from the ProGet UI. There is no case that we can have a "file vanish" as is happening to you.
The 404 error you keep getting is expected if there is a cached entry without a file. There is really no other way we can imagine to get that error. It's very common on Windows for files to "suddenly vanish" when you have anti-virus tools running --- a .jar files suddenly being written to disk will often trigger a quarantine action.
ProGet obviously cannot detect nor prevent this interference. You may be able to use a tool called ProcMon to monitor for interference: https://learn.microsoft.com/en-us/sysinternals/downloads/procmon
Otherwise, you may wish to just set up a AWS Lightsail sandbox, which can be done for pennies: https://docs.inedo.com/docs/proget/installation/proget-how-to-install-on-aws-lightsail
That will allow you to compare/contrast behavior.
Thanks,
Steve
Hi @michal-roszak_0767 ,
You can just click "edit" on an API Key in the UI to change the date or secret value.
However, if you have "Cryptographic hashing" enabled, then you will need to delete the key and recreate it to change the value.
Thanks,
Steve
Hi @phopkins_6694 ,
The "missing tags" is a regression from ProGet 2024.28 (PG-2911); it is a UI display issue and it's already been fixed in ProGet 2025.
Not sure about download counts, but there were some display changes in ProGet 2022 as well -- I think what you're seeing is the difference between "total downloads for all versions of the package" versus "downloads for this version".
Thanks,
Steve
Hi @mhelp_5176 ,
When upgrading ProGet 2024 and earlier via the Inedo Hub, the user performing the upgrade must have db_owner permission. So, this behavior is expected if <Domain>\MyLoggedInUser doesn't have access.
I'm not sure if you can log in to Windows using a gMSA or not. But, the easiest move is just to give <Domain>\MyLoggedInUser the appropriate access, or just switch to username/password authentication.
In ProGet 2025 and later, the ProGet application itself performs the upgrade, so that user account would need db_owner permission.
Thanks,
Steve
Hi @parthu-reddy ,
These indicate that your network stack is being overloaded. npm can do this, as it's sending thousands of simultaneous requests to your server. Each of these requests require multiple database connections (network) and requests to remote registries (network).
If you're using load balancing, you'll want to tweak the configuration to do rate limiting. For example, in npm it's this: https://blog.nginx.org/blog/rate-limiting-nginx
Hope that helps,
Steve