I tried on a different machine which runs Ubuntu 16.04.2 LTS and for some reason I no longer see the problem. Even more surprising is that both machines are virtual machines built from the same VirtualBox image. The 16.04 one was recently upgraded from 14.04. I guess 14.04 image is somehow broken and was fixed during the upgrade. I guess that's answers my question.

Hey Thanks for the pointer to the nginx fix, works a treat. Here is my docker-compose setup for anyone looking for a quick and great fix... version: '3' services: proget-web: image: inedo/proget:latest ports: - "888:80" hostname: proget-web restart: always volumes: - "/var/proget/extensions:/var.progetextensions" - "/var/proget/packages:/var/proget/packages" depends_on: - proget-postgres expose: - "888" proget-postgres: image: postgres:9.5 restart: always volumes: - "/etc/localtime:/etc/localtime:ro" - "/var/proget/db:/var/lib/postgresql/data" proxy: image: nginx:1.11 ports: - "2345:2345" volumes: - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro depends_on: - proget-web

Regarding the database migration, we don't have an export/import function.. but you can just recreate the feed and use the bulk import path for your exisitng packages.

Hello Matt, It looks like the PostgreSQL version of Feeds_SetLastSyncDate was not updated when the MSSQL version was. I've logged this as PG-1006 and it will be fixed in the next version of ProGet.

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!

This seems to be fixed as of the Docker image containing ProGet Version 4.7.14. The Docker image hash is: b7a3d6595c21d34997b4cbe6da9187801f410f17bff8e84228711bf29396a6ab pulled on 9/6/2017

Tried stoping the service that was tying up port 80. No help.

Well, for this, you would use the Download package endpoint There's a lot of guides out there on how to use cUrl (here's a good one), but a basic use would be... curl http://proget.local/upack/my-feed/download/my-group/my-package/1.2.3?contentOnly=zip -o my-package1.2.3.zip ... then you can just use unzip.

I have filed this as PG-757 and it is fixed for the next version.

We test with the latest version of Posgres, but I haven't heard of any issues with 9.4 or newer. This ought to recreate the missing tables in your database: CREATE TABLE "Licenses" ( "License_Id" SERIAL NOT NULL, "External_Id" VARCHAR(50) NOT NULL, "Title_Text" VARCHAR(200) NOT NULL, CONSTRAINT "PK__Licenses" PRIMARY KEY ("License_Id"), CONSTRAINT "CK__Licenses__External_Id" CHECK (RTRIM(LTRIM("External_Id")) <> ''), CONSTRAINT "UQ__Licenses__External_Id" UNIQUE ("External_Id") ); CREATE TABLE "LicenseUrls" ( "License_Id" INT NOT NULL, "License_Url" VARCHAR(400) NOT NULL, CONSTRAINT "FK__LicenseUrls__Licenses" FOREIGN KEY ("License_Id") REFERENCES "Licenses" ("License_Id") ON DELETE CASCADE, CONSTRAINT "CK__LicenseUrls__License_Url" CHECK ("License_Url" NOT LIKE 'http://%' AND "License_Url" NOT LIKE 'https://%'), CONSTRAINT "UQ__LicenseUrls__License_Url" UNIQUE ("License_Url") ); CREATE INDEX "IX__LicenseUrls__License_Id" ON "LicenseUrls" ("License_Id"); CREATE TABLE "LicenseRules" ( "LicenseRule_Id" SERIAL NOT NULL, "Feed_Id" INT NULL, "License_Id" INT NOT NULL, "Allow_Indicator" YNINDICATOR NOT NULL, CONSTRAINT "PK__LicenseRules" PRIMARY KEY ("LicenseRule_Id"), CONSTRAINT "FK__LicenseRules__Feeds" FOREIGN KEY ("Feed_Id") REFERENCES "Feeds" ("Feed_Id") ON DELETE CASCADE, CONSTRAINT "FK__LicenseRules__Licenses" FOREIGN KEY ("License_Id") REFERENCES "Licenses" ("License_Id") ON DELETE CASCADE ); CREATE INDEX "IX__LicenseRules__Feed_Id" ON "LicenseRules" ("Feed_Id"); ALTER TABLE "Feeds" ADD "AllowUnknownLicenses_Indicator" YNINDICATOR NULL; DROP TABLE "FeedLicenseUrls" CASCADE;

Thanks for the bug report. This will be fixed in v4.7.2, which should be released today. To upgrade, see the "Upgrading to a new version" section of this KB article: http://inedo.com/support/kb/1100/getting-started-with-proget-for-linux Basically though, when the container starts up it makes sure the database schema version is current, so all you really need to do is run the new container and point to the same data.

Thanks for the report. We'll have this fixed in v4.5.4, which will likely be available today.

I ran into the same issue when trying to run image on docker on windows (in linux container of course). First thing that I tried was to turn off proxy server. After that, instead of seeing an "Activation completed" message, activation request never finished. In the end I restored original proxy settings (same as system), restarted docker image and activation went without any issue automatically after restart.

BM-1997 - FIX: Transfer-Files operation can create files with \ characters on Linux Thanks very much. Works as expected :-)

Hi Alana, Thanks for the comprehensive answer. Looks like things are still quite away off then. It's a pity mono is not more stable right now, hopefully Microsoft will put in some investment, but it looks like SQL Server is not going to be available until for at least another year.

The size and last modified/write date are used to determine if a file changed, but in pre-4.9 versions, the local time the server creating the artifact is used in the zip file (instead of UTC), which meant the deployed timestamp could be wrong. That said, it wouldn't cause a full redeploy... only an incorrect timezone. So, let us know if you see behavior like this (or can repro it with a smaller, less important deployment). It's possible the SSH library we're using handles returning dates differently, and there's an edge case we need to address.

We're still working it... currently there are some issues surrounding the .NET 4.5 implementation in the Mono distribution, which we hope to see resolved soon!

Apparently only the PowerShell scripts support variables in parameters and in scripts at this time, so we will have to add this feature for shell scripts as well. Ideally it will be included with the initial 4.7 release, but may be a maintenance release behind that. For now, if you use the Execute Shell Script action and enter the script as text or a file, it should work as you expect.

Glad that works. If you only have a few instances of variables like $HOME, you can always just escape the $ - use $$HOME instead and BuildMaster will treat it like the literal $HOME and not try to replace anything.