Hi Luke, you'll want to put the connection string in quotes: bmdbupdate UPDATE /conn="Data Source=DB1;Initial Catalog=ProGet;Integrated Security=SSPI;User ID=Account;Password=Password;" We'll try to add that to a new version of the database updater! Cheers!

This isn't specific to ProGet at all, but HTTPS/SSL in general. It's not possible to bypass or address this from the server software (ProGet) side at all. You'll need to either trust the self-signed certificate on the client (Jenkins), install a certificate from a trusted root (server), or bypass that warning in the client (Jenkins).

We'll be fixing some of the bugs in the visual editor with regards to template arguments in a future maintenance release (hopefully 1.1.3); we've already made the changes in BuildMaster v5's editor, just need to bring them over.

What do you think of something like this? Of course it's not implemented, but just an idea... if $IsCollectRun || !$IsAutomaticallyTriggered { Ensure-Something-That-Requires-Reboot(); } So this way, the block would run during the collection run of the plan (which is where drift is detected/reported), and would only run if the job is manually triggered.

I'm afraid the Ensure operations are a bit trickier to write, mostly because they require the definition of a configuration template... The EnsureOperation<TConfig> class is designed to help make it simpler to write these... but we don't have a tutorial for those just yet. In the mean time, I've emailed you the source code of all of the built-in Operations and Configurations, so I hope that might be of some assistance.

It sounds like ProGet is working fine, but that the CHOCOLATEGUI doesn't support Windows Integrated Authentication. I would submit a ticket/bug request on their github and ask them to support it. It's generally a relatively easy change to make, depending on how they implemented querying.

In v4.8, you can set up a Retention Policy or go to Admin > Administrative Edits and purge an artifact. In v5, you will be able to do the same, but purge the artifact directly from the Release Package ("build") page. // I've updated the old question you linked as well

This appears to be a bug in the visual editor regarding templates... but if you switch to text-mode it should work. template my_template<$arg1,@arg2,out $arg3>{ ... blocks and content here ... }

Hmm, I wonder if it's related to Powershell Execution Policy? I'm not terribly familiar myself, but I know I've had to fiddle with that a bit to get things working... 15 Ways to Bypass the PowerShell Execution Policy

The easiest workaround is to declare the variable at the top of your plan. set @WebServerFeatures = @(...) Otherwise we will get this shipped by end of day!

That certainly does sound like a bug. We'll make sure to look into that. The syntax for calling a template in text mode is: call MyTemplate ( arg1: value, arg2: value ); So it's basically just like an Operation except for the keyword "call" in front. That is supposed to be documented here, but it looks like we don't have that listed yet. We'll also make sure to get that added to the docs before we're out of beta. Thanks!

Looks like a bug caused by accessing certain pages from clients that don't support gzip compression. We'll have this fixed in 4.0.15, which should be released today.

Looks like a bug caused by accessing certain pages from clients that don't support gzip compression. We'll have this fixed in 4.0.15, which should be released today. Thanks for the detailed report!

There are several ways to solve this problem, but a common approach is to multiple servers in each global location, and then either use connectors or replication to ensure the packages are accessible locally.

In this case, the error message means that the user runnin the installer does not have permission/access to read the configured ProGet database (this is an upgrade).

In BuildMaster v5, a global plan is intenteded for use in a pipeline stage/target. Use a global template (Plans > Templates), which can then be called as if it were an operation.

You could create a connector of this feed and add it to the other feed, so that you don't have to do any manual steps. It would act as remote connector and pull packages directly.

It was most certainly permissions related. From the 4.0 Upgrade Notes... If you modified any of the default roles but did not rename then, then they will renamed to the new task names. In addition, the role's individually-securable actions (formerly, "tasks") will be reset to the new, default definitions