TIL that PowerShell can use internal CLR generic reference type names like that! But really, please don't do that...
-
[System.Nullable``1[[System.Int32]]]
-
[Nullable[int]]
... much easier to read
TIL that PowerShell can use internal CLR generic reference type names like that! But really, please don't do that...
[System.Nullable``1[[System.Int32]]]
[Nullable[int]]
... much easier to read
You can ignore this error; for whatever reason, the NuGet client unexpectedly terminated the connection, and the result was that ProGEt stopped writing bytes. Not really anything to worry about.
The diagnostic center isn't for proactive-monitoring, more for diagnostic purposes. So ulnless users are reporting a problem, you don't need to check it.
Hi @andreas-unverdorben_1551 ,
npmjs.org primarily serves static content and runs on massive server farms running in Microsoft's datacenters.
Your ProGet server is much less powerful and does not serve static content. Not only is every request is dynamic (authentication, authorization, vulnerability checking, license checking, etc), but most requests (such as "what is the latest version of package X") need to be forwarded to npmjs.org and aggregated with local data.
So, a much less powerful server doing a lot more processing is going to be a little slower ;)
Running ProGet in a server cluster will certainly help.
Cheers,
Dean
Hi @kichikawa_2913,
We see multiple connectors pretty often, and it rarely presents a problem.
The main downside comes in the overhead of aggregation; for some queries like "list all package versions", each connector will need to be queried and have the results aggregated. So it could cause performance issues for for very high-traffic feeds - at least that's what we see on the support side of things.
However, if you plan on using a package-approval workflow, then it won't be a problem, as your approved-npm
feed wouldn't have any connectors.
Hope that gives some insight,
Dean
@joel-shuman_8427 thanks for the heads up!
I just updated it
https://github.com/Inedo/inedo-docs/blob/master/CONTRIBUTING.md
@jimbobmcgee thanks for the detailed analysis! This is on my list, but haven't had time to properly reproduce and test this.... but as you noted, the code fix looks so easy.
I just made a quick change (OT-513) and prerelease (2024.2-rc.1). Can you give it a shot?
https://docs.inedo.com/docs/installation/windows/howto-install-prerelease-product-versions
Hi @ghollosy_9163,
I'm afraid this will not be an easy problem to troubleshoot; there were some major changes in ProGet 5.3 with regards to Docker feeds, so it's possible that there was a data migration problem during the upgrade process.
Ultimately it looks like your container configuration files aren't there. I don't know why, but I'll try to point you to where/how they are stored.
Docker blobs are stored on disk, and you'll see files named by their hash. Based your screenshot, it'd be a file like bf3c18259....
. These files are also indexed in the database, in the DockerBlobs
table.
If the files aren't anywhere on disk, then check backups. It's possible they got accidently deleted, and you can just add them back.
If the files are missing on disk, then they are probably gone for ever. If they are not in the database, then perhaps something happened during the migration? I really don't know. It's possible to insert them in the database, but we don't have an automatic way to do this - basically you'd need to write a script.
-- Dean
hi @jaehyung-shin_8059 ,
If you click on the latest
tag, do you see any information about the packages in the container?
Container images are scanned on upload if they are small or queued to be scanned in the background if they are large. There are sometimes errors scanning containers, and if so, these errors will be logged... typically under Admin > Executions.
-- Dean
Hi @jaehyung-shin_8059 ,
From what you described, it sounds like you'd like to have a single tag (like :v3
) resolve to different architectures?
This is called a multi-platform image, and you'll need to study/follow the Docker guidance on how to create one: https://docs.docker.com/build/building/multi-platform/
Long story short, this is not something that you can do by simply pushing two images to the same tag like you're doing; it's quite a bit more complex, and you have to build the images in a very specific manner.
But once you do that, ProGet does indeed support them (they are called "fat manifests") and you will see a note/warning when viewing an image for one.
-- Dean
@parthu-reddy yes, but we do recommend migrating...
There are some known bugs/quirks with Maven (Classic) feeds and we will not fix them.
We will likely not migrate them to PostgresSQL, which means you won't be able to migrate to PostgreSQL in ProGet 2025+.
So it's likely that ProGet 2027 will not support them.
Hi @parthu-reddy ,
Huh... that's interesting... but not surprising. The Maven (New) feeds assume POM files are valid XML, but I guess Marvin supports invalid XML for POM files
I fixed this via PG-2859 which add Add Support for Invalid POM files on Maven (New) Feeds. You can access it via 2024.23-rc.1 on the prerelease feed (InedoHub), or the 24.0.23-rc.1
Docker image.
Hopefully this will work-around these migration issues.
-- Dean
Hi @parthu-reddy ,
This error means that the previously listed pom file (ant-1.6.5.pom) is somehow corrupted. It cannot be loaded as XML due to the error.
I assume it's this artifact:
https://repo1.maven.org/maven2/ant/ant/1.6.5/
That one is fine at the source. I would just remove it from your old/classic feed, since I assume it's just something from maven central. And it can then be downloaded again.
-- Dean
Hi @parthu-reddy,
For a major upgrade, we recommend to schedule a maintenance window and then stop traffic from the load balancer. Then, upgrade the servers.
For a maintenance release, it's fine to just upgrade them one at a time. It only take as few minutes to do that. There may be a few errors with the database/code being out of sync, but it likely will not cause any problems.
-- Dean
@parthu-reddy this is a somewhat expected error, and it's something we'll improve in a future version of ProGet, but in all a cases it will cause some kind of problem.
The problem is that you added a new feed/connector (in this case, a Maven (New)
) that is unknown to previous versions of ProGet. So when you try to load that unknown type in older versions of ProGet, you get this error.
If you deleted the connector before downgrading, it would have worked. So, I would upgrade, delete, then you can downgrade again.
-- Dean
@sneh-patel_0294 I don't think so, its only displayed on that page...