Check out the "Get Labeled" action under the "Source Control" group of actions. I'm using Git and that's how I pull the code associated with a tag. I'm pretty sure "Get Latest" does pull down the whole repo. In general, when automating application builds, you want the process to be as repeatable as possible, and relying on a repo to be maintained on the build server between builds introduces unnecessary complications.

Hi John, I just tested the fix, and it indeed solves the problem. I am impressed how quickly this was handled! Thanks a lot!

Every .NET project that consumes NuGet packages has a packages.config file, and that should be in source control. Unless I'm missing something, the deployment plan actions should be as simple as "Getting Latest" from TFS, then an "Install NuGet Packages" action followed by "Create NuGet Package".

Yes it would, but the editor UI may attempt to validate the credential. The way to get around this would be to edit the Action XML directly and replace the principal name with %VARNAME%. We'll add a fix in a future version of BuildMaster (likely 4.x) to bypass this validation if %[A-Z]% or something is matched.

Wow! Talk about agile, thank you for the quick turn around.

Ah, yes, that is indeed a bug. The home page "Browse" should link to the first available feed. I've logged this as PG-121 and we will fix in a future version of ProGet. The "Feeds" navigation link, however, will show the available packages.

Hello, We've identified a bug that's causing this.... it will be fixed in ProGet 2.1.3. In the meantime, if you email support at inedo.com, we will send a patch to resolve this. Thanks, Steve

I figured out the problem was with the cloud service name. I was including the build number in the name and it just so happens that build number includes the {Major}.{Minor} numbers. The period was ultimately throwing it off. If you want to include the build number, then you have to use a url friendly number.

Hello, Thanks for the reply. I have started pushing just the Symbols package, and this seems to be working really well. Thanks Gary

Hi Andrew, The ProcessRemoteCommand method only works when working with .NET-based agents. Behind the scenes, that method will serialize the action and use a sort of remoting to run that method on the remote server. With an SSH-based agent, this is obviously not possible. The CommandLineActionBase abstracts a lot of the complexity in executing remote processes. Just ignore the ProcessRemoteCommand method (throw a NotImplementedException) and try run the ExecuteCommandLine method from Execute. FYI - this is all being refactored in 4.0, and we're trying to phase out as many ProcessRemoteCommand-based actions as possible.

Hey, This is great news! Thanks for getting this sorted out so quickly! Gary

We uncovered the cases in which it might lock... this should be addressed in ProGet 2.1.2 (released today).

You should be able to use a variable server by editing the action's config xml, and replacing it with %VARNAME%; however, this is not supported in the editor, and will break once upgraded to 4.0. But, it will work. The Variable Server in XFer Files will be available in 4.0.

Hello, Would it be possible to ask a follow up question to this... Are you using Visual Studio 2010? I tried to find the setting that you mentioned here, but I can't find it in my Visual Studio 2010 setup, and I am wondering if this is only possible in Visual Studio 2012. Thanks Gary

You could use the ExtensionConfiguration_GetConfiguration method, e.g.: EXEC [dbo].[ExtensionConfiguration_GetConfiguration] 'Inedo.BuildMasterExtensions.Artifactory.ArtifactoryConfigurer,Artifactory', NULL, 'N' and get the Extension_Configuration column, which contains the XML serialized properties of what you need - some simple XPath should be able to retrieve them.

Thanks for the Answer Alex, I was able to get this to work. Maybe there should be a screenshot showing the Test environment's setup?

Great, many thanks for your support!

There's no specific error message, aside from the SQL error that's being thrown. Since you have both on the same server, perhaps it'd be best to have a single SQL Server instance (SQL Express), and have the BuildMaster and ProGet databases hosted in that server.

This is how the "default directory" is implemented (see http://inedo.com/support/documentation/buildmaster/deployment-automation/deployment-plans/actions). It allows for the same directory to be used as input/output. At the start of the action, the "WRK" directory is moved to "SRC" and a new "WRK" directory is created. If there are no files in "WRK" at the end of the action, "WRK" is deleted and "SRC" is renamed to "WRK". Otherwise, SRC is deleted.

Sorry about that - there was a bug with that action in BuildMaster versions pre-v3.6.5 (specifically BM-1137). If you upgrade to the newest version of BuildMaster the "Set File Attributes" action with your masks will function as intended.