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

Thanks! We will have this fixed in ProGet 4.0.14, which will be released within the hour.

Thanks for your response. I'm glad to see that this will be fixed in the next release. For the time being, could you please specify which URL individual users should use, because every URL I've tried so far results in a SecuredTaskDeniedException

In my original example that I used, the web user did have permissions. In fact, the user I used was the admin user. I did both create a special user with delete attributes and test the admin user. Both results were the same. Success was reported, but the package never really was deleted. I'm not using a feed APIKey, I'm only using users that have appropriate rights to do certain things, like delete.

Those 2 steps are working now. I can work on adding back the other steps in the plan/pipeline. Thanks for your help.

When you download a package, then package is cached by default; if you download aggin, it will use your local cache instead of re-downloading from npm. The caching is transparent, so they will not show up as local packages.

Thanks Alana. Could you guide me to-what table should I be making what changes?

This is by design; symbols work quite weirdly for native packages, and don't follow consistent conventions like .NET packages. So, we can't arbitrarily strip all .pdb files (we only remove them from the /lib path). In this case, we suggest to make a separate symbols feed.

We will explore this further; NuGet 3.4 added new abbrebrivations that we will be supporting in the next maintenance release.