Hello Jeff, There is currently a bug in the FeedCleanup task for Docker feeds. PG-1030 has been fixed for the next version of ProGet, but until then, disable the FeedCleanup task for any Docker feeds in /administration/scheduled-tasks.

This error means that the user running the installer doesn't have access to the database in the connection string in the config file on disk. You'll need dbo access to the database in order to perform the upgrade.

There doesn't appear to be; but we have a new issue (BM-3034) for this. If it's easy to do, we'll get it in ASAP!

Discussion should be moved to a new post or followed here: http://inedo.com/support/questions/6554

Hi Alana, Thank you for the update. I was quite surprised too when realised we can't use case insensitive collation in Postgres. But what if we have 2 columns, one contains data as is, and one contains normalised data, e.g. Login and LoginNormalized. The first one is indexed, the last one is used in queries. But I understand this leads to different schemas in SQL Server and Postgres. I completely agree we can bet on SQL Server, but I don't know its licensing options yet. Posgres is working well from my point of view, except this detail. Since a lot of web applications use Postgres and I haven't heard about case sensitive logins yet, I believe that solution exists. Thank you for all of your hard work on this awesome project!

As of v5.6, the "SQL Change Scripts" feature is designed with these principles in mind: Database Changes Done Right. Run once and only once Impossible to be “un-run In order to accomplish this, a metadata table is created in the database (__BuildMasterDbSchemaChanges2) to track which change scripts have already been run. Before running a script, this table is queried. Regarding "resetting" the idea that a script is run, the best bet is to delete and re-add it from BuildMaster. You can also restore that particular database.

OK ; in this case, can you provide a simple reproduction case that we can try? Like, a new application that reproduces this? And please send this as a ticket -- Q&A are generally the lowest priority when it comes to support, so we want to handle it through better channels :) The $ApplicatinName and $ReleaseNumber are standard test cases for us, so they do work in our config file replacement tests (which, are quite complex due to so many legacy cosniderations...)

The Operation does nto currently support this; ApplyLabelOperation.cs is the source code, so perhaps it wouldn't be too hard to customize?

I would also try to upgrade your new server to 4.7.6 as well, because I really can't think of anything in the ProGet software that would yield this behavior. The file's bytes are simply written to disk as they are received using streams and async methods. Moreover, we test with large packages and have a lot of users who have large packages, and none have reported issues.

It seems like something changed in security settings - Publish Packages task got "private" scope. [image: vo6hmcg.png] I droped "Publishers" and added them again, scope has been changed to "all feeds" and problem gone! [image: NEDd3NU.png] Seems it's an upgrade bug because the scope option can't be set in free version... [image: 8qyYRQ3.png]

And also see this post.

The npm search command has been broken in npm for some time, as it downloads the entire package index and searches it locally. Due to the size of the index on npmjs.org, this stopped working for a lot of people due to npm OutOfMemory errors and various other issues. Because of this, they deprecated this form of searching in the npm client in favor of a new search API, but it seems that only npm 4+ actually uses the new API. Indexing all of npmjs.org also caused a lot of problems for our users due to the sheer amount of data involved, so we dropped indexing of any registry that supports the search API. Local packages are still returned in the /-/all endpoint, since this doesn't require the same server overhead, which is why you are still seeing those packages. Basically, you may want to try the new npm client, or just stick to searching on the web for now.

Hello Peter, Thanks for the bug report! I was able to reproduce the problem, and it will be fixed in the next minor version of ProGet (4.7.12). PG-1029

Hello Jason, It looks like the npm registry started returning empty responses about a week ago. It looks like they're having caching problems. ProGet 4.7.8 and newer support the npm search API, so indexing isn't needed to search the npm registry, or you can wait for npm to fix the problem on their end.

UPDATE: this has been updated in PG-1632 __ Hello Jonas, Deleting images isn't in the native API because the stored procedures only delete metadata, but if your CI server has access to the database ProGet is using, you can run the stored procedure to delete the metadata for the image and ProGet will automatically delete the files whenever the FeedCleanup scheduled task next runs. Assuming your docker image is named proget:443/foo/bar/baz, the foo feed has ID 42, and the digest for the version of the image you want to delete is f52fbd32b2b3b86ff88ef6c490628285f482af15ddcb29541f94bcf526a3f6c7, this SQL statement will work: EXEC [DockerImages_DeleteImage] /* Feed_Id */ 42, /* Repository_Name*/ 'bar/baz', /* Image_Digest */ 'f52fbd32b2b3b86ff88ef6c490628285f482af15ddcb29541f94bcf526a3f6c7' GO If you don't know the digest, https://proget/api/json/DockerImages_GetImages?API_Key=[your API key from /administration/api-keys]&Feed_Id=42&Repository_Name=bar/baz returns metadata including Image_Digest and Published_Date, and https://proget/api/json/DockerImages_GetTags?API_Key=[your API key from /administration/api-keys]&Feed_Id=42&Repository_Name=bar/baz returns metadata including Image_Digest and Tag_Name.

Maven repositories are traditionally just file systems organized by convention, either local or exposed using a simple web server, so a lot of repos get this "for free" by just enabling directory listings for URLs. ProGet works a bit differently and simulates some of the traditional maven structure, so it's not necessarily trivial for us to implement this; that's not so say we can't do it, just that it wasn't deemed essential. While I don't think that this is formally part of any maven specification, a lot of other repositories do it, so it's been on our "maybe" list for some time; we just haven't had a lot of interest in it so far, so it hasn't made it onto the roadmap. We'll reevaluate what it would take to do it, and add it to the roadmap if we think it's something we can work in soon.

This has been address in v4, but asa workaround, just use the "Browser tools" to edit the text on the page, and unhide the edit buttons.

We had switched to IIS hosting of the web site, and so the solution was to first stop the web site in IIS Manager before running the installer.

Sorry for the confusion... I think those should be listed as "internal only" methods, and not on the API page. Anyway, the Native API can only be used for metadata. So you won't be able to use it in this manner.