Thanks, I'll add this as a feature request; there should be a link on the "perform manual action page" that links to the execution, but you can see all current executions on the home page dashboard.

You could use a different workflow (or in v5, "pipelines" as they will be called)... and then have a different build importer/feed on each. Alternatively, you could not use the build importer, and just have a build step download the package and incorporate it as an artifact.

Thanks Jon, I've added this as an issue -> https://github.com/Inedo/bmx-nuget/issues/14 We'll likely get this in v5, since we want to do some additional refactoring as well. And perhaps updagde the client version.

Thanks Alana, that's very useful to be aware of, I'll follow up with the nuget team as well.

Ah, yes... definitely a bug. Seems to be related to some unanticipated changes in the latest WMF preview, but easy for us to fix. Can you please try upgrading to v1.0.3? Also please note that, due to a bug in the latest WMF5, it now appears you may need to specify a module name for some non-built in resources; it's supposed to be optional, and search all installed modules if not specified. We don't know when Microsoft will fix this, but the work-around is fairly simple: PSDsc xWebAdministration::xWebAppPool ( Name: AccountsAppPool, Ensure: present );

Alana. I have made a pull request https://github.com/Inedo/bmx-windows/pull/30 Thanks for pointing me in that direction. It was indeed very easy to modify the codebase.

To migrate ProGet to a new server is as follows: If you're using a local database, back it up and restore it on the new server If you're using a local package store, copy those to the new server (ideally same exact path) Install the same version of ProGet on the new server, pointing to the new database Change whatever IIS settings you desire From the web app, edit whatever settings may have changed from the Admin section

This would be very easy to do with a PowerShell script, so as an immediate solution, I'd suggest to do that. It'd also be very easy to patch/modify that particular action (CreateIisAppPoolAction.cs) That being said, this all applies to the "v4 execution engine", which will very soon be replaced with an indescribably better execution engine (the one that Otter currently uses). When we migrate the "v4 App Pool Action" to the "v5 App Pool Operation", it will basically look like the Ensure-AppPool Operation. So, as you continue to explore BuildMaster, do keep this in mind :) If you're doing server/infrastructure configuration (which, creating applications is definitely a part of), I'd strongly recommend looking at Otter as well!

This is unfortunately not trivial to debug, and will require understanding/learning how the symbol/source serving work (and the arcane tools to inspect said files), since it could be any number of things at this point, from your local pdb cache to improperly build pdb files. But take a look at some of the other Q&A posts with symbols tag, specifically this one which shows how to use pdbstr.exe to inspect. If you find out specifically what the issue was, please do share it.

Hi Joel, thanks so much for trying out Otter! The best place for issues would on the Submit Ticket form, but you're also welcome to email us direct at support - at Inedo - dot com. Pricing software is always difficult, but we tried to keep it competitive with other IaC tools, which are still insanely less than traditional SLM tools (BladeLogic, etc). So, we're open to suggestions on all fronts, including that! Perhaps your case is much different than we had imagined. As of v1, the only difference between the free and enterprise editions is that the free version provides unrestricted access for all users (i.e. everyone's an admin). For some of our early adopters, it made sense, because they have: dozens of important, regulated production servers hundreds of less-important dev/lab servers So, in that case, they would have a Lab (Free) and a Production (Enterprise) instance.

Hi Mike, Apologies for the delay, but the problem is with the NuGet extension for BuildMaster. There is a new version (4.7.2) available that can be updated from within BuildMaster on the Admin > Extensions page.

Awesome!! Thanks guys!!

ProGet is licensed per server, therefore this scenario requires 2 licenses. I believe the FAQ you are referring to is for one of our other products BuildMaster that is licensed per user, which allows the same key to be used in test instances.

Unfortunately, that's not uncommon. Keep in mind the remote registry is a gigantic JSON file that ProGet downloads and then processes. What's happening is that npmjs.org is just inexplicitly terminating the connection during the download. You could be downloading it too slowly, too fast, or who knows? You can try it again, and maybe it will work. Some users have reported that downloading the file from a different network, and then hosting that file on a local server works fine.

Yes, that's the directory used by the "local agent", for the buildmaster server.

thx for the guidance

Hi, great question; yes, that would be doable through the API, but we're still putting the final touches on that. The "full API" would necessarily expose the entire complex model that's used behind the scenes (e.g. differentiating between jobs, job templates, and executions, etc), which from our experience is a real pain to work with, because it requires you to become experts of the domain model. Then you have to authenticate to it, etc. So, perhaps we'll also have a more intuitive API that looks a lot more like the web interface, and exactly like you said, has a simple url for a "kick me now" button of sorts. In the mean time, i'd definitely check it out to see how close it is to your requirements, and we would be happy to work with you to get a PoC going. It's still 1.0, but that's how we improve and get to 2.0 and so forth :)

HTTPS/Certificates are at the socket layer... below ProGet's application layer. We're not familiar enough with Bower's internals, but it's most likely just using the operating system's network stack, and reporting warnings/errors from the underlying components. Likely it's a certificate trust issue between your computer and the ProGet server, or some intermediate authority. So, while there's nothing we can do on the PRoGet side, hopefully this helps point you in the right direction.

It should "just work", but when it doesn't there are so many things that it could be. Often times, the API/libraries from Microsoft that we use to query AD simply return no results (and no error messages, either). So, you'd have to check the ProGet logs, the Windows Event logs, and Active Directory logs as well. 80% of the times, it's permissions related; i.e. the ProGet web service account user does not have permission to query appropriately.