If you are facing the issue with Sourcetree, that you can not push to your Azure DevOps repository, because it fails with the following error:
Pushing to https://bitfoxhungary.visualstudio.com/someProject/_git/someProject
fatal: unable to access 'https://bitfoxhungary.visualstudio.com/someProject/_git/someProject/': The requested URL returned error: 403
Copy the URL returned by the error, and browse it with a web browser.
If needed, provide your login credentials in the browser, then try again.
This content has 3 years. Some of the information in this post may be out of date or no longer work. Please, read this page keeping its age in your mind.
In case you need a private NuGet feed, you can do it in Azure DevOps. This can be handy for businesses reusing their code between several codebases.
What will contain the example
In this tutorial, I will show you how to share code through NuGet packages so that it can be used in multiple projects. The Example will walk you through the game engine of an IDLE game. IDLE games are games that do not require much user interaction. The point of games is that they run or produce even when the user is not playing them. The goods produced offline can eventually be used by the player, to upgrade producers or to buy more producers.
The game engine is developed on the IDLEGAMEENGINE branch. Different games, such as a restaurant game or a programming game, can use this game engine. The games have a common logic of operation, only the story of the games differs. This design helps in development to fix bugs by only having to fix the bug in one place and it will be fixed in all games.
Step 0: Create your shared code
I will not go into details about the implementation of the game engine in this tutorial. The point is to create source code that you want to share with other source code.
Step 1: Create the NuGet feed
Go to your projects Azure DevOps site, and select Artifacts from the list on the left. Push the Create feed button. You can select from several visibility options for the new feed.
Step 2. Automate NuGet package publish to the feed
You probably have a repository with the code, what you want to share. Go To Pipelines on the left, then create a pipeline to get NuGet packages published automatically. (If you are experienced, you can make Release pipelines) In the following sections, i will guide you through how to make a CI pipeline, to pack and publish the NuGet packages automatically every time the main branch gets updated.
Go to pipelines and Select create pipeline button.
Select where do you store the code what you want to publish to your private NuGet feed. In my case, I store the GameEngine code in Azure DevOps, so I will continue with this.
Select the Repository which contains the code to be shared.
Select the desired build template for the project. I’ve implemented the core code in .NET Core, so i will continue with ASP.NET Core.
By default this template creates you a NuGetToolInstaller task, a Nugetcommand Task, and a VS Build task.
We will add a 4th task which can be added by searching for NuGet task.
Set up the tasks parameters as the following: Command should be push. The path to the NuGet packages to publish should be the path where the VSBuild builds the application.
Select the target feed location properly. My target feed is at the same organization, so it will appear in the dropdown list. For External NuGet server, you will need to specify a connector to that resource.
Save the pipeline and run it. If you have configured everything correctly, you will see a lot of green ticks in the progress window
When you navigate to the Artifacts/Packages section, you will see that the NuGet package has been pushed successfully to the private feed.
Step 3.: Use your private repository on your projects
In order to use the recently updated package, you will need to set up your local Visual Studio instance to be able to use your private feed.
Go to your VS settings, select the NuGet section, and click on the Sources subsection. Click On add and define the connection details presented by clicking the “Connect to feed” button in the Azure DevOps / artifacts section.
Once you have configured the Visual Studio well, you will see the NuGet Package available when you are trying to add a new package to your proejct.
This content has 3 years. Some of the information in this post may be out of date or no longer work. Please, read this page keeping its age in your mind.
When trying to sync or pull our repository from remote, it fails with the following error:
The pull operation failed, see Output Window for details.
In the output window, the error is the following:
Cannot determine the organization name for this 'dev.azure.com' remote URL. Ensure the `credential.useHttpPath` configuration value is set, or set the organization name as the user in the remote URL '{org}@dev.azure.com'.
Go to Visual Studio’s Tools, and then Options, search for ‘Git’ in the searchbar.
Select the Git Global Settings option, and find the ‘Credential helper’ setting, and set it from ‘Unset’ to:
GCM For Windows
This should solve your problem.
This content has 3 years. Some of the information in this post may be out of date or no longer work. Please, read this page keeping its age in your mind.
This tutorial will drive you through setting up a great CI/CD pipeline for Xamarin Android in a fully hosted Azure DevOps enviroment.
Part 1 contains:
Creating an empty Xamarin.Android build pipeline
Uploading keystore file to secure files
Start with some code
I have added some basic code to my demo repository. It is a boilerplate Xamarin Application, with no additional customized code. If you have code in your repo, make sure it builds successfully.
Create your first pipeline
On the left side menu, go to Pipelines/Pipelines. This menu will show up a welcome page, to create new pipeline.
Click on ‘Create Pipeline’ button, or if you have already created your first pipeline, find a button to add a new one.
On the next page, a wizard will guide you through the basic setup.
If you have your code in Azure Repos, click the button for that.
Select your repository where your Xamarin Android code lives.
On the next page, you can select a template to create your pipeline yml. Let’s choose Xamarin.Android.
If you want, you can rename your yml file. Pipeline files will be placed in your repository root by default. YML file extension stands for YAML files. Review your newly created file, how it looks like. Luckily, you do not have to write yaml too much, but good to know, how it markups the build process.
Okay it is enough for now, we have some things to do outside of the pipeline editor. Go save your configuration.
Create a new branch for the pipeline setup with name like pipeline_configuration. You can directly push the config to the main branch, but in this step of the tutorial, i recommend to create a branch for that. Later on, we will set branch policies 😉
Store your app signing key securely
Your app signing key is a very important file to keep your binaries trusted for your users. You can provide with signing, that the binary has been built by you, and not by a bad guy. Keeping this file secure is a must have thing.
Azure DevOps pipelines have a library function, where you can store your custom agent connection settings, and files needed to build or sign your applications securely.
Let’s jump into library menu. Select secure files option, and upload your keystore file.
If you do not have a keystore, you can create a new one when you are trying to publish a Xamarin.Android application as AdHoc. Keep your Alias, Password in mind, you will need this in the future.
The location of the release keystores on Mac is:
~/Library/Developer/Xamarin/Keystore/
Once, you have uploaded your keystore to the secure file storage, you need to set the permissions, to pipelines in order to access your secure files. Note your secure file filename, you will need this too in the future. Click the three dots on the uploaded file, and select edit.
Check the pipeline permissions checkbox, and save your file.
In the next session
We will continue set up CI to our Android project.
Go to Part 2 to continue configuring your repository
This content has 3 years. Some of the information in this post may be out of date or no longer work. Please, read this page keeping its age in your mind.
If you want to access your Git based repository with SourceTree, you need to genereate a Personal Access Token for your account in DevOps. Follow the tutorial above:
After you have done with setting up PAT, set up SourceTree on Mac:
SourceTree > Preferences
Accounts > Add…
Enter your devops server url. ex: https://AnAwesomeCompany.visualstudio.com/ As username, enter your e-mail address As password, paste your private access token Set the protocol to HTTPS.
After the success configuration, you will see your remote repositories on the main screen of Remotes section.
This content has 4 years. Some of the information in this post may be out of date or no longer work. Please, read this page keeping its age in your mind.