Hi @bryan-ellis_2367 , I'm not an Azure DevOps expert, but last I checked, it's not possible to add NuGet package sources other than it's own ADO Packages product or the public repositories. That may just refer to "upstream sources", but I'm not totally sure. However, if you want to use the ADO Pipeline's built-in NuGet commands to publish packages, I guess you can set up a service connection using this? https://docs.microsoft.com/en-us/azure/devops/pipelines/library/service-endpoints?view=azure-devops&tabs=yaml#nuget-service-connection Not totally sure -- but please let us know what you find :) Cheers, Alana

This appears to be an issue with the TFS credentials provider - the 401 status code means credentials were not supplied (and the error message confirms that as well); but typically clients should followup with a 2nd request that includes credentials when the 401 is received. If credentials are actually sent and are invalid/forbidden, then a 403 would be returned by ProGet.

I found my mistake I had to specify the "Feed API user" in the API Key configuration.

Please refer to the Upgrading Extensions section of the v6.0 upgrade notes.

This error message is coming from the NuGet client, and it's regrading your server's SSL configuration. Unfortunately I don't have enough information about your server or network configuration to tell you how to begin troubleshooting, but if you search that error, you can find lots of tips on how to ensure you have certificates set-up properly, etc.

TFS labels can be a bit complicated, and the way that Visual Studio (GUI) vs tools (tf.exe, BuildMaster, etc) interact with them are different. What may be happening in the GUI is that multiple labels are being created with the same name, and the the GUI is "searching" for files by label name (as opposed to "getting" those files). If you were to do a tf.exe get (https://docs.microsoft.com/en-us/vsts/tfvc/get-command?view=vsts), for example, you should see the same behavior. Instead, makes sure to first create a label at the $/ root level (e.g. tf label myLabel $/ ), and then you can sub-label items.

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.

To be honest, "SCM Triggers" are in a "quasi-legacy" state, because they use the "Legacy Providers". As such, we don't list it as a feature, and we hide the button on installations without SCM Providers configured. This was done slowly over the course of two years, in various v5 versions, to gauge user reaction. So, your inquiry is good feedback. That being said, we have not yet put a lot of effort into properly redesigning this feature. The reason for this, is that the "general direction" has been moving towards post-commit hooks; i.e. triggering the build from the SCM server, once a merge request (or something?) happens. Even on dedicated CI tools, the preference is shifting towards this route. I think this is because the branching logic has been too complicated to follow (even for really advanced CI servers like Jenkins and TC). So I wonder, have you looked into post-commit hooks? Otherwise, we are definitely considering a general-purpose poll/trigger feature: basically, a poll will periodically occur, and if a condition is met, trigger some sort of event. This would be shared across multiple products, and the usecases might vary based on the product. One motivation to develop this feature is that it will allow us to really feature the "BuildMaster is from source to production" story, which is becoming more popular again. Most people didn't want that, but now the pendulum is swinging back to it, now that source code tools (like Git) are integrating (totally inadequate) build/release features. In any case, none of this is all that "immediate", but I wanted to share reasoning to you about this, and solicit your feedback. Of course, if you need to create "legacy components" we can help you do that as well. We don't plan on removing those from BUildMaster, just hiding them so no new users can access them.

That worked. Also, I did not need to specify the API key since the user uploading the vsix was a service account with permissions.

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!

This is currently on our roadmap

This error appears to be related an extension missing. I would stop/start the agent, which should cause the extension to reload

hi Mark, great question. My team pointed me to your question; I actually talk on this topic quite a bit. DevOps is really just a buzzword, and everyone (including Inedo) is jumping on it to describe what we do. But ultimately, DevOps is a process improvement designed to improve release velocity (e.g. going agile) through two means: Automate everything you can Increase collaboration between teams Ultimately it's about improving a process of software release. There's a ton of noise about "best practices" out there, and everyone has opinions. But I think the best way to understand these opinions are to get a feel for the underlying process. Two suggestions for that. Release Management Done Right describes why you should be following a pipeline strategy. Source Control Done Right goes over how source control should/shouldn't be used, and is still quite relevant today (it was written before "DevOps" was buzzy). Now, based on your specific situation, my advice is to start simple. Just change-up your TFS version strategy a little bit -- don't build in each environment, but create a build artifact at the start. You can do this all in BuildMaster. The other tools are nice, but may not be necessary until you run into the problem of trying to have a single tool do it all.

Hello; this sounds like a NuGet/TFS question, I don't think we'll be able to help much. I would suggest to post to Microsoft forums or stackoverflow.

The TFS libraries used by the 4.9 and 5.x are different; sometimes, the workspace gets corrupted. To address this, it needs to be deleted on the server (unfortunately, deleting files on disk isn't enough). Please don't hesitate to contact support directly w/ any 5.x issues; it was a major upgrade, and while a lot of the changes were documented in various upgrade notes, we're quite familiar with common issues.

I was able to get Otter to work with TFS Git on-premises. All I needed to do was set the Otter website and service to run as a specific domain user that has rights to the TFS Git repository. Then in the Raft settings, leave the username and password empty. The Otter code will use the "DefaultCredentials" in LibGit2Sharp., which are the credentials of the currently executing service user. This is slightly sub-optimal, but it works. The next thing I would like to understand is why Git rafts are so slow (going to assets is fairly slow to load, ~10 sec) P.S. I never tried setting the "Basic Authentication" in TFS you recommended, as it is a fundamental change that could affect other users and services.

Well be releasing BuildMaster 5.1 in just a bit (later today), which will have these operations.

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").