Copying John's answer from StackOverflow: Maps are specified as %(key: value), here is an example plan that should help: set %map = %(Web.config: @("Web.Beta.config", "Web.Release.config")); foreach $key in @MapKeys(%map) { set @values = %map[$key]; Log-Information `$key = $key; Log-Information `@values = $Join(", ", @values); } Sleep 3;

It's not currently supported, but we'll consider doing it through the API or CLI at some point.

This would require a custom operation to capture this text. You could also use a tool like sqlcmd.exe to output the result to the textfile.

This is supposed to check every hour. If it's not, sounds like the service's task runner isn't running. Just restart the service, then its should be ok.

In this case, the account that the buildMaster service is running under is not an active directory account, or does not have permission inside of ProGet.

Definitely; this feature is certainly slated for redesign, to bring it more in the line of a "scheduled job" concept, and unifying implementation across our products (ProGet, Otter, Hedgehog as well). This concept of "don't run this job if an execution associated with this job is currently running" is how it could be implemented/described I suppose

Thanks Jon! This is not an uncommon pattern, it's something I call the "quasi-custom software" problem. I.e. you have a "small" number of customers (dozens not thousands), and each customer gets (1) small customizations to a common platform, and/or (2) customer-driven testing and rollout scheduling. In BuildMaster, I have seem both patterns; the "customer per app" seems to work the best when you need individual workflows and customizations, and then you can just deploy artifacts from the "core" app. Having seen this problem for many years, I have yet to see any tool that will "properly" model the situation; Octopus does have an interesting "multi-tenant" feature, but it's not so well suited for individual maintenance workflows. In my mind, this is a key benefit to the "quasi-custom software" model that companies like yours provide. That said, I think we will have definitely have better handling for this in our next generation of tooling (i.e. Hedgehog). Projects will lend better to sharing than applications, and one of our usecase for nested projects will be grouping customers in this manner Universal/romp packages will be able to be bundled, allowing for an easy conceptualization of the "quasi-custom" code as well It's not a huge departure from BuildMaster now, but it will just be much easier to handle I think!

The situation with Azure is a bit confusing; I will put a note in to the docs team that it should support asset storage, but it can not support large/chunked uploads because of the limitations of the blob storage API that Alana mentioned.

It's just an unfortunate mix of terminology in "promotion" vs "deployment" vs "execution". A "promotion" is simply allowing a package to be deployed to the stage and should only happen once per release. A "deployment" can happen anywhere but may be restricted by pipeline settings depending on if the package was previously promoted, and an "execution" is essentially the worker that performs the deployment (and there could be many per deployment). The fix will make it perform a deployment instead of a promotion then a deployment, so it will work as you're expecting.

The NuGet URL should be http://proget.edlund.dk/nuget/Edlund , not /feeds/

Changing the name during a promotion can't be done, primarily because that's the key that identifies which packages are promoted. Would it be feasible to create another package with the same contents and non-pre-release name in the Dev Feed, then promote that?

Yes, if you create a Artifact Retention policy with these options: Only purge artifacts in deployed releases Only purge artifacts in rejected packages

Hi Alana, Thanks for your reply. I ended up submitting a bug Ticket which I need to respond to. But in response to your comment, The Agent and the runtime user are both the same account. Aside from the simple script above, I also tried to get it to return the value, and it would only return 's' in once case, error in another , or indicate the value was part of a Dictionary, which I'm guessing is meaning its within an array. Tod Hoven is my contact for the issue that I will be working with, but at the moment my BuildMaster instance is offline, so I will be following-up once our environment is back online. I'll try and remember to update this thread with the fix once we have it... -Trent

Basically, the template doesn't represent valid OtterScript, and that's why there is an error. Basically, this is not a valid OtterScript statement: $Increment(${index}, 1); You can, however, do this: set ${index} = $Increment(${index}, 1); Except, the "set" statement is not supported in a text template, which means you cannot do what you're doing. You could probably work something out with $foreach $i in @Range(...), but it could get a little messy.

This is a false positive; unfortunately we seem to be the target of many of them :( See http://inedo.com/support/kb/1113/anti-malware-false-positives-code-signing-and-safety-of-inedo-products Please report the false positive, because some of the virus total companies will not let us do it, only their customers.

I see what happened, I looked under Servers where I would have thought that info would be but instead it's under General in the docs.

Hey Alex, Thanks for the follow up! I did continue working on this, and got to a point where I'm happy with how it is working. I was in contact with Karl about it too via email, and sent him some details, but for reference for others who find it useful.. We went with the solution of putting the config into separate files, using the 'configSource' option as needed to specify references to external files. Further to that, we created an extension for Otter to allow us to manage the settings in those files - similar to how the 'EnsureAppSetting' thing works, but allowing an XPath expression to be used to identify the precise element in the config file to check. That meant we could use it for e.g. files that hold connection strings. (I do intend to publish that extension to the Den at some point - haven't so far gotten around to it though). Let me know if you would like any more detail on what we're doing! Thanks, Andrew

That was too easy and it was right there in the error message. I need a facepalm emoji right now. Thanks for the quick response!

The docker image is no longer in Beta, FYI.

Hello Bruce, I believe the Jenkins plugin does not want the leading slash on the path, so this should work: parent-folder,myFolder/**/* Let me know if I misunderstood your question - I don't usually work with Jenkins.