I'm migrating all our "workflows 4.9.7" to pipelines 5... then converting our legacy plans to the new plans...maybe in the future will not so often than now...but actually I have that situation almost every time, and sometimes the errors appears after 10 or 20 minutes of an execution...

In ProGet v4.2, there is an option right under Disk Path that says Package Store. [image: vYDcll0.png]

Yes, it's posible, and that's a common workflow; there are operations to do all of these things. I would try to follow the [BuildMaster tutorials])(/support/tutorials), some of them have some workflow similar to what you're doing. The other things (like SEnd Email, Execute SQL Scripts) are just differnet types of operations you can run during a plan.

If it's showing up on the one page, but not the other, then i'd say it's definitely a bug. I've logged as PG-595, so we will look to fix in next maintenance version.

This is only available as a legacy action as of 5.2.1; there is no corresponding Operation built for it yet, but we will get one going soon.

Alright, v5.1.2 was released and it should be correct now :)

If you're able to get it up and running, then we'll definitely support as per usual. Basically we just don't have the knowledge/expertise to help install / set-it up on Azure (we haven't even tried it ourselves). But it should work... they seem to support a lot more parity with regular SQL Server, and a lot of installs are on SQL Azure.

Please refer to the ProGet Silent Installation page.

Hello, I was not able to reproduce this. Here is what I did. Create a new PowerShell Asset... Name: Test Script Parameters: none One ambient variable: MyEnvVar ==> $EnvVar Contents : Write-Host My var is $MyEnvVar; Create a variable on MYSERVER: $EnvVar = my server var Create a new application with a deployment plan that has a single action (targeting MYSERVER) that calls Test Script Output is My var is my server var, as expected I also deleted $EnvVar from the server, and then created it on an environment the server is associated with, and it works as expected. When I deleted $EnvVar from the environments, it produced the literal output (My var is $MyEnvVar) upon running. So, my guess is there's a typo somewhere... best, Alana

Understood! Thanks for the quick response. Btw, it would also be nice to have a "Clear All" button in the recent errors section, because when we start having a ton of the same error, it fills it up and we can't clear them easily. Thanks again!

This is not currently supported, though we will look to add this in a future version. pguinstall.exe was never intended to be run by another process, or run silently, etc. It's only meant to be called interactively, via the "Remove Programs" dialog. We will look to add an uninstall script in a future version, but for now this isn't supported. You could always write a simple powershell script, and remove the service, webapp, and installation directory. That's pretty much all that is installed.

As of v4.2.0, the ProGet Chocolately package does not have an uninstall script. At the time we build the package, the uninstall scripts were not at all in common use or recommended. However, in the latest version of Chocolately, it seems the client inspects the registry to see what was added to the "remove programs" keys, and then attempts to run the commands. Like most "uninstallers", pguinstall.exe was never intended to be run by another process, or run silently, etc. It's only meant to be called interactively, via the "Remove Programs" dialog. We will look to add an uninstall script in a future version, but for now this isn't supported.

It looks like this was caused by a packaging issue with installation; this impacts some upgrades and certain Linux-based querying from the web app (i.e. if you just save, and don't validate, it should work).. You can manually fix by going to the BuildMaster installation directory and: Delete the libssh2.dll file from the Web\bin directory Copy the Service\lib directory to the Web\bin directory (so Web\bin also contains the lib directory) We will of course get an updated installer built as well, but this should get things working for you until then.

It looks like the Legacy Plan Importer currently does not support the ExecutionStatusPredicate and ReleaseStatusPredicate, which is throwing the error; we will fix this in a maintenace release, but as a work-around you can delete the predicate before converting.

The error you shared was: An error occurred processing a PUT request to {url}: Invalid user name or password. A PUT request is what the NuGet client does to push packages to a feed. You'd want to look for a message related to GET or other requests. But, if you're seeing an unknown, then the problem is likely authentication related, but you'd have to look in the error log, it could be a bad url too... You can always try run fiddler, and attach ProGet to the fiddler proxy server to see precicely the requests that proget is making as well.

Hi, Great thanks. Just what I needed. I couldn't work out how to get the list to work. David

The Jenkins / ProGet Plugin has been updated to Version 0.3 with the following changes: Expand variable correctly Some basic validation on the version number If you update, then it should work!

If the feed is reporting "healthy" that means that an initial check passed. The 500-status errors will be logged on Admin > Error Logs; without seeing those, it's not really possible for us to advise on what the issue is. Hopefully that will give insight as to what could be failing. You may need to attach a proxy server between ProGet and MyGet (e.g., install Fiddler on the server, then point ProGet to use the Fiddler proxy), in order to capture the traffic.

I updated the default schema on the security group I was using to dbo and I was able to run a successful install. Thank you!

I know this is a really really old thread but I thought I would share something that we did for our continuous integration builds / deployment process. Every build drop location for each build definition will contain a "Latest" folder in addition to the "versioned" folders that contains the output of each build. At the end of our build template, we perform the standard activity of placing the build artifacts in the versioned dropped location. For SUCCESSFUL builds, we copy the contents of the drop location and update the "Latest" folder. If a build fails for some reason, we leave the contents of the Latest folder alone. Our nightly automated package and deployment processes (for automated integration testing) have been simplified to always pull from the "Latest" folder. They can determine if the folder contains the same version as the last one or if it's been updated.