Eric, thank you! That was the issue, I didn't know about that issue.

Hi Upgrade Path : Serveur Run the Hub installer on your Otter server -> https://s3.amazonaws.com/cdn.inedo.com/downloads/desktophub/OtterInstaller.exe Extensions (In Admin Menu) /!\ Git Extension shows 1.0.3 after its upgrade while it is expected 1.0.4. but it is working fine Agents. Do not update agent using Otter (Upgrade Agent). I had some trouble with this option. I'd rather upgrade using my software deploiement tools - (Remove old agent, cleanup folder, install new agent) Best Regards Philippe

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!

If you want to extend the life of that directory so you can view it in process explorer you can do something like this in the deployment plan: with async { Git-GetSource( # ... ); } with async { Sleep 1000; } await; That will keep the directory around for long enough to examine the file locks, and the deployment can be cancelled when finished.

Hi Alana, Sorry to say that the solution you propose is crap. If teamcity can monitor on wildcards, example +:refs/heads/release/* I'm sure BM can somewhat do it also. I raised a ticket for the purpose. EDO-3200. Thanks Regards

The extension should be available now.

Hello Alana, Thank you for reply. Adding "Delete Files" step before "Get Git Source" worked for me. Deleted files don't appear in newly created artifacts anymore. cheers, Milan

Hi David, I came across your post and noticed that you're experiencing an issue with Git source providers in BuildMaster. I understand that you're trying to use the "Get Git Source" command but can only get the source from the master branch. Based on the command you provided, it looks like you have the syntax partially correct. However, it seems that the code is being picked up from the master branch instead of the production branch that you specified. Have you tried specifying the branch name with the "refs/heads/" prefix? For example: bash Copy code Branch: refs/heads/PRODUCTION This may help in correctly identifying the production branch. Additionally, you mentioned that you have deleted the repo details from C:\BuildMaster_WEBTMP\SrcRepos, but are still facing the same issue. Have you tried clearing your Git credentials and re-entering them? It's possible that the issue may be related to authentication. Plus I was researching on Elmedia Player for Mac, and As someone who's been using Elmedia Player for Mac for quite some time, I can definitely say that it's a great media player that offers a lot of useful features. One thing I particularly appreciate about Elmedia Player is its ability to play virtually any video or audio format that you throw at it.

It looks like this was caused by a packaging issue with installation; this impacts some upgrades and certain Linux-based querying from the web app (i.e. if you just save, and don't validate, it should work).. You can manually fix by going to the BuildMaster installation directory and: Delete the libssh2.dll file from the Web\bin directory Copy the Service\lib directory to the Web\bin directory (so Web\bin also contains the lib directory) We will of course get an updated installer built as well, but this should get things working for you until then.

Looks like there was a packaging issue with the 1.2.0 installer. We'll get a fixed installer posted right away, but you can fix in the meantime by going to the Otter install directory (default is Program Files\Otter) and copying the lib and NativeBinaries directories from the Service directory to the Web\bin directory.

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.

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.

Tod, I have resolved my problem. Where I select "server" on new git repo setup, I shouldn't have chosen the target server, but the server, where buildmaster (and git) is running. This confused me. Thanks for attention, Milan

The reason you have to Get Latest is because otherwise if you built straight from the BuildMaster-managed "ScrRepo" directory, there would be artifacts from the SCM tool also included (for git, .git files), and other times added files from the BuildMaster build steps that you wouldn't want stored with the repo. Once you "Get Latest" somewhere, you can operate on a fresh set of files to perform whatever build tasks are necessary for deployment. Note the "Get Latest" action will essentially perform a clone or pull from BitBucket, then copy the files to the source directory of the action.

Currently, the Git provider only monitors a specific branch + path combination in source control. You can however, set up multiple SCM-triggered builds, each pointing at the desired "release/*" branch.

hallo farhan, wurden Sie TFS? können Sie versuchen, löschen Sie das Verzeichnis "GitRepositories" im build svctmp Ordner? Das sollte das Problem beheben.

When you say "BuildMaster is not able to see it", are you saying you aren't able to get the latest files in that branch, or that when you browse the branches in the file/folder picker that they aren't visible? I just did a quick test with a Git repository on BitBucket and the moment I added a remote branch, it became visible in the file/folder picker.

Which aspect of insecurity are you referring to? Those credentials (as long as they are sent over SSL) are encrypted before they are transmitted. If you mean storing them in the BuildMaster database, of course that does leave them available to anyone who has access to them, but you can configure permissions to hide debug logs and access to the configuration for that provider. Anyway, you should configure your git client to use key-based authentication if the username/password combo can't be done.

I appear to have found the answer. On a windows server you need to set up a network share with the git repository you want to share. Then, on the BuildMaster provider page, set the remote URL to file:////YourServer/path/to/git This will allow you to create a git provider that's on the same network as your BuildMaster server without SSH or git protocol.

Thanks for the info. In regard to switching the exe.. should I be able to save the change from using the built in exe to a standard one without hitting the "Test Connection" button? When I try switching to an external git.exe and click the "Save" button, I can open the provider properties back up and the "Use Standard Git Client" option is unchecked again. Any other changes I make seem to save, just not changes to that option. The same thing happens when I create a totally new provider / source as well. I set it up to "Use Standard Git Client" and hit save then open the new connection up and it shows as unselected.