Topics created by pdickers_0718

Not a basic question, we're always working to make BuildMaster as easy to use as possible, so getting feedback on how to improve our docs and tutorials will be great :) If you haven't seen it already, we've recently updated our Azure DevOps Integration Documentation; there's a lot of content there, and we hope to continue to make it easier and include tutorials at some point. Basically though, I recommend you start with Create New Application > Azure DevOps CI/CD. That will create an application with the Azure DevOps CI/CD Template, and you can see how a "full CI/CD" would work. It should just build "out of the box", and use our publicly-available AzureDevOps repository. What your'e describing, it seems like just a small portion of that. Once you've got the manual process working, it's just a matter of creating a Git repository monitor. you can configure that to monitor the branches in your AzureDevOps repository. https://docs.inedo.com/docs/buildmaster/ci-cd/continuous-integration/build-triggers/repository-monitors

I discovered one more error detail. BuildMaster logged an error that it couldn't use the folder (for the "get latest" copy on the build server) because it belonged to a workspace for a different account. I believe this is because I changed from using a domain account to a local account on the TFS server machine for the TFS connection from the BuildMaster machine. I deleted the workspace for the previous account. I edited the TFS connection in BuildMaster, entered the account information for the local account that I am now using, and saved it without doing a "Test Connection". Now, everything seems to be working okay. This installation of BuildMaster has been through many upgrades. Maybe someday I will do a full uninstall and a clean install of the latest version, and build new applications in that version, etc. If anyone needs to know, I found (and then deleted as needed) the TFS workspaces as follows (this is using TFS 2017 and Visual Studio 2017). On my workstation with Visual Studio 2017 installed, I ran the "Visual Studio 2017"-"Developer Command Prompt". This opens a command prompt window with all the appropriate environment variables set to allow the "TF" command to be used. Then, run: tf vc workspaces /owner:* /computer:* /collection:"http://URL-for-TFS-collection/" to show all the existing workspaces (this shows username and workstation as well). To delete an existing workspace, use a command like this (note that this uses the singular form "workspace" where the previous command uses the plural "workspaces"): tf vc workspace /delete /collection:"http://URL-for-TFS-collection/" WORKSPACE-NAME;USERNAME-for-the-workspace This will let you know if there are any pending changes in the workspace, and ask if you are sure you want to delete the workspace.

Thanks for posting an update! Anecdotally, this used to happen to us "all the time" when rebooting a hypervisor server (i.e. server hosting multiple VMs) because the host/hypervisor server didn't have enough resources to give to each booting virtual machine, and SQL Server couldn't start due to low start-up resources (memory, etc). We've mostly corrected this by staggering start times and increasing VM hardware.

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

This should be fixed in the 5.0 beta, which we will probably have available for download this week. Basically, we are dropping those _WRK, _SRC, directories entirely from OtterScript plans in favor of something a little easier to reason about. We'll have more information about this behavior in an article soon.

Thanks for letting us know; this is something we want to work very consistently in 5.0, so it's possible it's working half the "old" way (OtterScript plan wrapping an old action), and half the new way (a new "operation").

We just released our TFS2012 extension - http://inedo.com/buildmaster/extensions/tfs2012