Posts made by atripp

Hi @frei_zs ,

Unfortunately we don't know what aptly is doing behind-the-scenes and can't guess what could be going on here. I don't believe that ProGet is generating that file; it looks like something aptly is doing based on data downloaded from ProGet.

ProGet implements a Debian repository as specified here:
https://wiki.debian.org/DebianRepository

It's possible that there's a bug in our implementation, or a bug in aptly, or both. But we can't really track it down with the information here :(

Your best bet would be to start with the aptly team, and to see if they have any idea.

Cheers,
Alana

Hi @philippe-camelio_3885 ,

We haven't investigated or changed this code in very many years (especially within the last year), so I wouldn't expect a changed result.

Can you try the same troubleshooting steps as above? To find out where the invalid JSON is? Maybe it's comma again?

FYI - we use Newtonsoft.Json for both serializing and deserializing (as you can see from error). It's really odd to be generating invalid JSON, but that's what the message is It could be related to an obscure bug, etc. We just have no idea and haven't investigated in past year.

Thanks,
Alana

@frei_zs I'm also replied to your ticket (EDO-10276), but wanted to reply here as well. I'm going to lock this thread after, since it's a different issue.

Unfortunately "tar" files are more of a convention than a standard, and not all libraries can read files created with different libraries. We are using one of the most "forgiving" tar libraries (we use four different ones!) in this particular scenario, but maybe aptly conventions aren't forgiving enough?

FYI - here is what we're doing with the library

public byte[] ReadControlBytes()
{
    using var control = TarReader.Open(this.Control);
    while (control.MoveToNextEntry())
    {
        if (control.Entry.Key == "./control")
        {
            var bytes = new byte[control.Entry.Size];
            using var entry = control.OpenEntryStream();
            ReadBlock(entry, bytes);
            return bytes;
        }
    }

    throw new InvalidPackageException("Package does not have a control file.");
}

We will need to inspect the file and see if we can determine what's wrong, and if it's an easy fix, we'll do it.

Hi @philippe-camelio_3885 ,

Thanks for sharing that, I was able to find the issue.

The two feeds - public-ubuntu are missing public-zabbix are missing the property feedType. This is a bug in BuildMaster for not validating the data in that case and in ProGet for not sending it. So we will fix both:

• PG-2617 FIX: FeedManagement API not returning feedType for debian feeds
• BM-3942 FIX: Improve error handling for ProGet connection calidation

In the meantime, as a work-around, you can block those feeds from your API key, so they can't be read. They aren't usable in BuildMaster anyway, and that will prevent the bad data from being returned, which is what's making the API break.

Thanks,
Alana

@hashim-abu-gellban_3562 nice find, correct that was a typo :)

Hi @hashim-abu-gellban_3562 ,

If you need to authenticate to the feed, you need to pass an API key using Basic authentication., with api as the username and your key as the password.

Here is one way to do this in PowerShell.

$user = 'api'
$pass = 'abcdefg12345'
$pair = "$($user):$($pass)"
$encodedCreds = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($pair))
$basicAuthValue = "Basic $encodedCreds"
$Headers = @{
    Authorization = $basicAuthValue
}

$url = "https://myprogetserver/feeds/mynuggets/package/mypackage/1.0.0"
$destination = "c:\mypackages\mypackage-1.0.0.zip"
Invoke-WebRequest -Uri $url -OutFile $destination -Headers $Headers

I would recommend first getting your scripts to work without authentication, then add it in later.

Cheers,
Alana

Hi @rick-kramer_9238 ,

We have seen cases where LDAP/AD is painfully slow; one common reason is that "recursive group search" is enabled.

But before digging into that, I would just temporary disable Windows Auth (do this in IIS) and disable LDAP/AD, so that you're only loggin in with a built-in username/password. If it's still really slow, then you know it's unrelated.

Best,
Alana

Hi @v-makkenze_6348,

It's hard to say for sure, but there's clearly some kind of database timeout problem here when running Projects_GetReleaseAnalyzerData . I suppose you could try running that directly, and see if it takes a long time?

I suspect the issue is that you have too many active releases. This is a major issue with ProGet 2023's feature -- it was designed with the assumption that users would archive releases, but we've seen thousands in the field. If you have a lot of active releases, this cause some big performance issues.

ProGet 2024 auto-archives builds (the new word for releases).

Cheers,
Alana

Good news @m-karing_2439 ,

This works in ProGet 2024! More specifically, when rewriting/refactoring the PyPi feed, we added support for this "unconventional" repository - specifically, one that doesn't follow the /simple convention or use any of the JSON/warehouse api.

Cheers,
Alana

Hi @philippe-camelio_3885 ,

Can you share the results of /api/management/feeds/list (on ProGet) using the API token you specified?

With that we can hopefully spot something.

Thanks,
Alana

Hi @jw

You're correct, the general design philosophy is to hide elements (links, buttons, pages, panels, etc.) when a user does not have the appropriate permissions.

As you also might imagine, it's hard to get that right all the time and obviously it's not a high-priority in testing (internally) or reporting (users/externally).... so if you spot places where it's incorrect, let us know. We're always keen to improve the UI/UX :)

Best,
Alana

Hi @hashim-abu-gellban_3562 ,

If you plan to use the NuGet API, it's best to familiarize yourself with how it works. We do not document this API nor provide examples, we simply implement Microsoft's API. Here area few links that may be helpful:

• https://learn.microsoft.com/en-us/nuget/api/overview
• https://learn.microsoft.com/en-us/nuget/api/package-publish-resource

When Basic authentication is required, you can use api/{your-key} for username/password. You can learn more about API keys in ProGet here:

• https://docs.inedo.com/docs/proget-administration-security-api-keys

As an alternative, you may find ProGet's Common Package API to be easier to use; we also document it and have several examples:

• https://docs.inedo.com/docs/proget-api-common-package

Best,
Alana

@forbzie22_0253 you can use the same ProGet Free on multiple instances

Thanks for the bug report @philippe-camelio_3885 !

I logged as OT-508 , and we'll target it an upcoming maintenance release :)

Hi @scott-wright_8356 ,

You can ignore that message; not sure how/why it occurred, but the consequence is that the message that the license key was updated wasn't immediately dispatched to the other nodes due to some timint issue. So that means it could take a few minutes for the other nodes to reflect the new license key.

We should probably just ignore that error. let us know if you keep seeing "No primary service node has been registered." and we can investigate further.

Best,
Alana

Thanks @jw, we still aren't quite sure what's behind this, but we rewrote PgvdVulnerabilities_UpdateIndex procedure to run much faster:

This will be included in ProGet 2023.32 via PG-2615

I just published ProGet 2023.32-rc.1 as a pre-release ; would you mind to try it out on your test server, since you can reproduce it?

https://docs.inedo.com/docs/howto-install-prerelease-product-versions

Hi @v-makkenze_6348 ,

I wasn't sure what version you're on. I'm not able to reproduce this in ProGet 2023.32, so I wonder if it's a possibly a bug in an earlier version of ProGet 2023? We recently made some fixes.

How did you try to add the license as Package name?

Did you manually edit the license, or use the dialog to add the entry?

Thanks,
Alana

Hi @v-makkenze_6348,

Just want to confirm here -- it sounds like it's working, except the issue now that you're only seeing 634 packages but not 363?

One thing I suspect is that one of the packageurls in the SBOM is invalid (incorrect format). Are you able to find which item isn't being imported?

It might be missing a version or something else?

Thanks,
Alana

@jw That is so weird.

Is it always failing with the follow?

Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host..

Looking over your Prod dates... did you happen to upgrade after 2024.03.14? Or maybe that's when you enabled the preview feature?

Could you try running sp_updatestats and cleaning fragmentation on those tables usig SQL Management Studio? Clearly there's something we're missing here...

Thanks,
Alana

Hi @Justinvolved ,

This is not uncommon with PowerShell; in general the processes will be closed, but there are enough scenarios with long-running/hanging PowerShell scripts where those processes will report termination but the process will not be terminated. So they can stick around

I'd recommend using the Inedo Agent instead, even if it's on the same sever. That gives better process isolation compared to the local agent, and you shouldn't see this behavior for too long. The local agent runs in-process.

Cheers,
Alana

Hi @jw ,

This job should take like a minute tops. It's inserting/updating about 50k vulnerability records (PgvdVulnerabilities) and maybe 200k related package records (PgvdPackageNames). The later packages tend to have more related packages, but not that many. In either case that's not a lot for SQL Server.

Any help in troubleshooting would be appreciated, since we're kind of at a loss. Behind the scenes, the PgvdVulnerabilities_UpdateIndex procedure is being called with batches of 1000 vulnerability records, and it's exclusively locking both tables.

We noticed that micro-instances of SQL Server (e.g. 1 core / 512MB ram) would fail without batching, but otherwise it completes in about 5 minutes. I assume you're not running that?

One user reported an unpatched SQL 2016 had a severe performance issue with an OUTPUT clause we were using, so we stopped using that. Now it works in that version.

Maybe it's another SQL Server bug? Or perhaps something we're otherwise missing?

Maybe a forced sp_updatestats would do the trick? Or cleaning up fragmentation on those tables (again, shouldn't be a problem....)

Any insight would be helpful. We don't know how to rewrite this any more effectively, and batches of 1000 seem about as small as we want to make them.

Thanks,
Alana

FYI - we plan to fix this in ProGet 2023.32 via PG-2613

Hi @m-karing_2439 ,

Unfortunately, this repository doesn't following PyPI repository conventions.

For example:

• No way to see latest packages (should be https://download.pytorch.org/whl/cu118/rss/updates.xml)
• Does not return anything for /simple listing (e.g. https://download.pytorch.org/whl/cu118/simple)
• Does not support JSON-based API to retrieve package metatadata

I guess it "happens to work" in pip , or perhaps they install a plugin that allows it to work... but ProGet is designed around PyPi repository specs. which is why a non-confirming download site won't work very well.
I'll add a note to investigate this further, but for the time being you should just download the wheels and upload them to a feed in ProGet.

Cheers,
Alana

Hi @scott-wright_8356,

I looked into this further; for Maven feeds, the Connector Health Check simply queries the downloaded index. If there is no downloaded index, then it reports back as healthy. If there's an error with the index, it reports an error. However, most maven repositories don't have a downloadable index.

Anyway the health check is not very useful, and we plan to revisit the functionality in the future, since there's really no way to determine if ProGet can download an artifact unless you know the exact name.

Thanks,
Alana

@appplat_4310 thanks for the update!

We also applied the patch to the next maintenance release, so you shouldn't have any issues going forward then!

Hi @scott-wright_8356,

It's a bit hard to figure out how to help or troubleshoot with the information here, but a few key points:

• A "healthy" Maven connector doesn't really mean much; just that the URL can be accessed by the ProGet server.
• A Maven repository (like the one you are linking to) is just a "web file system" with url/folder based conventions
• A Maven "package" consists of a .pom file and zero or more other files (.jar); think of it liked an unzipped package that you can add/delete files from
• This is why you can't import only .jar files - you need the .pom file (which serves as the package manifest)
• Sometime marvin "packages" contain malformed .pom files that happen to work in some versions of the client, and ProGet will sometimes error on reading those; maybe that's what happening here

To help on this, we'll need to know specifically where the issue is and have instructions on how to reproduce it on a new feed/instance of ProGet.

First, I would start by trying to download the .pom file and .jar files from Google (like that gradle one you found), then upload them to ProGet from the Web UI. If that doesn't work, then we know the POM file is probably bad, and we can investigate it.

Next, I would try to pull the pom/jar from a connector. If that doesn't work (but uploading it does), then maybe the "API" for that repository is incorrect. And we can investigate it.

Best,
Alana

Hi @scott-wright_8356 ,

I'm not sure, but based on this URL:
https://maven.google.com/web/index.html#android.arch.core:common:1.1.1

I can see that the POM for android.arch.core.common 1.1.1 is located here:
https://dl.google.com/android/maven2/android/arch/core/common/1.1.1/common-1.1.1.pom

So the base URL would be:
https://dl.google.com/android/maven2

That should work, since maven works by convention. You will not see a listing of artifacts unfortunately, since Maven does not provide an index. You just need to know the articats by name, then append maven-metadata.xml.

As expected, the metadata file for that artifact is here:
https://dl.google.com/android/maven2/android/arch/core/common/maven-metadata.xml

Cheers,
Alana

Hi @forbzie22_0253 , that's only possible in the one-off GUI option. It's not possible if you're using a drop path

Hello, just letting you know we're aware of the issue and plan to investigate/fix soon! And we hope then to get your feedback on the preview feature :)

Hi @scott-wright_8356 ,

Thanks; it sounds like the underlying issue is indeed Google Android connector you added. I don't have an information or idea on why that might be the case... some third-party repos (Maven, PyPi, NuGet, etc.) are just really slow and buggy.

ProGet is basically acting like a proxy server here, so "garbage in, garbage out" applies - if the connector is slow and error-prone, then you will experience slowness and errors.

Sometimes third-party repos will create packages that don't follow the specifications but just happen to work in certain versions of clients. That could be what's happening here. In cases like that, we can really only address those on a case-by-case basis, and we'd need to know exactly how to reproduce the error and investigate it later.

Best,
Alana

Hi @forbzie22_0253

The use case you're describing (i.e. using drop paths as an intermediate to publish packages to ProGet) is not uncommon. It's fine, and can be simpler in many cases.

But since you asked... the downsides are that require file share access, new developers may be confused by the process (since the typical workflow is publishing directly), and that there is a lack of immediate feedback mechanism (just because file copy is success doesn't mean package is accepted). I guess those are all obvious.

As to your other questions...

Can ProGet handle situations where multiple computers are trying to install a module from the feed while at the same time that module is being updated by the dropPath feature?

Package versions are immutable and not meant to be overwritten. Instead you are supposed to publish new versions. If your workflow involves continuously overwriting the same version while continuously consuming it, you will get errors. Regardless of using drop paths or publishing.

Could these be potential file locking situations where a package is copied to the drop path and ProGet is trying to access it in the dropPath?

If the file in a drop path is locked for reading (since it's currently being written), ProGet will just try again later.

Hi @scott-wright_8356 ,

Can you try downgrading to 2023.30? I see some Maven changes, and any time there's a possibility of a regression. That will at least tell us where the issue might be.

Thanks,
Alana

Hi @scott-wright_8356 ,

You can change if you'd like, I'm not sure if it makes any difference with .NET6+ applications.

Cheers,
Alana

Hi @appplat_4310 ,

In 2023.31, we made made introduced various database performance improvements (deadlock, timeout reductions) via PG-2606, so it's possibly related to that. The query you identified most definitely helped, and it there's only one place it's called.

WE would be super-grateful if you could try running this?

ALTER PROCEDURE [NuGet_GetPackage]
(
	@Feed_Id INT,
	@Package_Id VARCHAR(255),
	@Version_Text VARCHAR(255) = NULL
)
AS
BEGIN

	SET NOCOUNT ON

	SELECT *
	  FROM [NuGetFeedPackageVersions_Extended] 
	 WHERE [Feed_Id] = @Feed_Id
	   AND [PackageGroup_Name] IS NULL
	   AND [PackageType_Name] = 'nuget'
	   AND [Package_Name_Lower] = LOWER(@Package_Id)
	   AND (@Version_Text IS NULL OR [Package_Version] = @Version_Text)
END

We believe that, for some reason, your query analyzer is following a different plan, but the new conditionals should force it to use the right index.

Let us know, and we'll get it fixed right away.

Thanks,
Alana

Hi @rick-kramer_9238 , you could certainly try to enable those and see if they help or make a change.

@scott-wright_8356 the Inedo Hub will upgrade the database code (stored procs, views) when doing an installation. So from the time you upgrade the first server to the last server of a cluster, the "database code" and "server code" will be "out of sync", yielding errors like this.

For most users it's okay, and they will typically (manually) upgrade all nodes over the course of a few minutes during a mtaintenance period etc.

Hi @jw , thanks for pointing this out! I added a note to review/investigate this in our run-up to finalizing ProGet 2024.

Hi @philippe-camelio_3885,

Without looking closer or testing it's hard to say, but that error sounds like the property isn't being set? You can see rom the the source code of Git::Checkout-Code, the BranchOrCommit argument (called Objectish in the code) will use DefaultValue of $commit unless a property is specified .

I guess just as a test, does set $commit = master make any difference?

Thanks,
Alana

Hi @rick-kramer_9238 ,

It's possible that the IIS App-pool is automatically shutting down, which can lead to a "warm up" time that's required on a first request. However, this is typically measured in seconds in slow cases, not minutes. So it shouldn't take that long to "warm up".

Unfortunately this isn't easy to troubleshoot, and it seems to be related to some kind of strange IIS configuration. We've heard of users solving it lots of different ways, from switching servers to uninstalling IIS, to switching to the Integrated Web Server. But no idea what actually works.

The easiest thing to do, you may want to consider switching to the Integrated Web Server. Microsoft recommends that over IIS these days as well. The quickest way to do this is to uninstall ProGet (this does not delete database or packages), then reinstall to use the integrated web server. Make sure to point to same database at install time. You can configure HTTPS later.

Best,
Alana

Hi @gurdip-sira_1271 ,

That message means that the Login for GLOBAL\GLOPROGET01$ does not exist at the SQL Server level; you can add this in SQL Server Management Stuiod, under Security > Logins.

Cheers,
Alana

Hello,

I am copy-pasting the same reply made to EDO-10211 -- feel free to reply to one or the other.

We'll do our best to help, but based on the information you provided, it sounds like your server might be "overloaded" and have more traffic than it can handle. I would recommend trying out ProGet 2023.31 (releasing later today) which has a few more performance tweaks, but if that doesn't solve the issue than it will involve looking at ways to expand server/clsuter capacity or reduce/throttle traffic.

The error you shared is unfortunately unrelated, and is just a generic "client disconnected" error - it will occur if a a client (web browser, etc) disconnects prior a request being received. These should not be logged, but due to a known issue in .NET6 they are. This should be fixed in .NET8 (ProGet 2024).

Best place to check is ProGet Diagnostic Center, under Admin. That will have the most relavent errors.

Best,
Alana

Hi @forbzie22_0253 ,

(Sorry this is basically a copy/paste of the same answer to @philippe-camelio_3885 's question)

We haven't run into any of these issues in our testing, but this error is a "generic database timeout", which is implying that "something" is going on with the database. That's the only information we have, "something".

To troubleshoot this, you'll need to use some of SQL Server's performance/activity monitoring tools to spot what's going on at the time. It could be anything from outdated statistics to a missing index to a bad query. Or who knows.

With ProGet, timeouts can happen during extremely high usage of feeds/server. We have also seen instances where SQL Server's auto-statistics aren't working, and rebooting the server will help -- you can try running sp_UpdateStatistics as well. I have never seen that personally, but two users reported this already.

Best,
Alana

Hi @philippe-camelio_3885 ,

We haven't run into any of these issues in our testing, but this error is a "generic database timeout", which is implying that "something" is going on with the database. That's the only information we have, "something".

To troubleshoot this, you'll need to use some of SQL Server's performance/activity monitoring tools to spot what's going on at the time. It could be anything from outdated statistics to a missing index to a bad query. Or who knows.

Best,
Alana

Hi @philippe-camelio_3885,

We do not support "sub-path content/URL Rewriting" in any of our products and strongly discourage even trying. It won't work and will just lead to lots of wasted time and headaches, since everything from javascript ajax requests to CSS background images to cookies assumes a well-known root path of / for the application.

Best,
Alana

Hi @philippe-camelio_3885 ,

In BuildMaster 2022, we redesigned the Git and Source Control experience, which required significant changes to the various Git extensions (Git, GitHub, GitLab, and AzureDevOps).

With these changes, instead of using service-specific operations like GitHub::Get-Source, you can simply use operations like Git::Checkout-Code. Behind the scenes, BuildMaster wires everything up using build variables like $Repository and $Commit.

In Otter, you'll need to specify those variables or To and BranchOrCommit properties, similar to this:

Git::Checkout-Code
(
    To: $DossierVisHab,
    From: gitlab-vishab
    BranchOrCommit: master,
 );

The extensions are indeed the same between BuildMAster and Otter, but they do different things than before. Now, the GitLab extension mostly just provides integration into Issue Tracking, and information intended for the BuildMaster UI, such as a list of organizations, repositories, etc.

Best,
Alana

Hi @philippe-camelio_3885,

I didn't realize it was possible to create those in Otter

I thought only Generic Git repositories work. There's no GitLab/Github/etc.-specific functionality available in Otter, those are primarily intended for BuildMaster's integrations.

I would just use Generic Git repository, since the Git-base doperations will all be the same.

Cheers,
Alana

Hi @mahdy-merry_6333 ,

It's possible, and you can do this by creating a second feed that effectively proxies the first feed and uses disk storage. You could use a Connector on the two feeds or REplication.

Cheers,
Alana

Hi @matt-wood_5559 ,

Looks like your account was added to My Inedo incorrectly due to a human error (someone manually added it on our end since you had been talking to sales)... but it looks like its already been corrected, and you have a working key to use now. You shouldn't have any issues going forward.

Cheers,
Alana

@appplat_4310 yes please :)

Once I get confirmation it works, i'll commit the changes so it goes in the next maintenance release

It's really hard to say, but that's probably it. We'd really need to analyze it further to tell. How many packages are in the release?

FYI - this is all getting a "total rewrite" in ProGet 2024, and you can preview some of the features in the latest release of PRoGet