How to build GitHub project with Azure DevOps
The purpose of this article is to show in very simple step how to create, configure and setup a build pipeline on Azure DevOps environment, using source code coming from GitHub.
… With some other trick 😉
- Azure DevOps account (you can choose “free account”, or use your GitHub account)
- Basic knowledge about YAML syntax
- Overview on Predefined Pipeline variables
- Add UpdateVersion powershell script to your repository
- … A project to build
- How to build ASP.NET Core application with JWT authentication
- Update .csproj and package.json version
Create a pipeline
- Login into your AzureDev Ops account
- If you have no project, create a new one
- from left menù click on “Pipelines” menù
- Choose Builds
- Choose your source location. For me is GitHub
- Choose the repository you want to take the source code to build
- Accept all request to make Azure DevOps able to read/write from your GitHub repository.
This is necessary because the file that contains the pipeline definition is going to be created on your GitHub repository.
- Create a pipeline from scratch, is easier than start from zero. I’ve chosen “ASP.NET Core (.NET Framework)”
tip: if you have an existing one, you can choose the option “Existing Azure Pipelines YAML file”.
You have almost done: your build could be ready to be used as is.
But, there is a few things that could be interesting to add to pipeline. Do you remember this article: Update .csproj and package.json version? I’m going to show you how apply it.
# ASP.NET Core (.NET Framework) # Build and test ASP.NET Core projects targeting the full .NET Framework. # Add steps that publish symbols, save build artifacts, and more: # https://docs.microsoft.com/azure/devops/pipelines/languages/dotnet-core trigger: - master pool: vmImage: 'windows-latest' variables: solution: '**/*.sln' buildPlatform: 'Any CPU' buildConfiguration: 'Release' name: $(BuildID)_$(Date:yyyyMMdd)$(Rev:.r) steps: - task: PowerShell@2 inputs: filePath: '$(System.DefaultWorkingDirectory)\Install\UpdateVersion.ps1' arguments: '-BUILD $(Build.BuildId)' workingDirectory: '$(System.DefaultWorkingDirectory)' - task: NuGetToolInstaller@1 - task: NuGetCommand@2 inputs: restoreSolution: '$(solution)' - task: VSBuild@1 inputs: solution: '$(solution)' msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:DesktopBuildPackageLocation="$(build.artifactStagingDirectory)\WebApp.zip" /p:DeployIisAppPath="Default Web Site"' platform: '$(buildPlatform)' configuration: '$(buildConfiguration)' - task: PublishBuildArtifacts@1 inputs: PathtoPublish: '$(Build.ArtifactStagingDirectory)' ArtifactName: 'WebApp.zip' publishLocation: 'Container'
As you can see, the generated pipeline looks like a YAML file.
There are 4 principal section that we use:
In this section is contained the Continuous Integration setting.
Is easier manage it from pipeline triggers menù, reachable from top-right menù, near “run” blue button.
By default is enabled, if you want to be able to control it, you have to declare ” Override the YAML continuous integration trigger from here”
What agent run your pipeline.
If you are interested on it, you can read the official documentation here
Some user-defined variable used in build steps.
You can choose to override the predefined build run name.
The build name is an identifier that allow you to refer to a specific build.
I’ve changed the default one with:
$(BuildID)_$(Date:yyyyMMdd)$(Rev:.r) , because for me is easier match the build number in file version if the run number show it. In my case, form that run number predicate I’ve obtained:
31_20191222.1 as run name.
if you want to learn more, you can take a look to official documentation.
This is the real build definition. Into step definition, there are several tasks.
Each task is run sequentially
On each task you can use your user-defined variable or predefined variables.
You can add a new task in easy way: click on “Show assistant” button on top-right corner (), this button opens a sidebar which contains the tasks you can add to your pipeline.
On each task you can choose to configure it editing the YAML file, or clicking on “setting” shortcut, just before task name: this open a new sidebar where you can configure the task.
CRTL+SPACE keyboard shortcut on YAML file to show autocomplete drop down menu.
- task: PowerShell@2 inputs: filePath: '$(System.DefaultWorkingDirectory)\Install\UpdateVersion.ps1' arguments: '-BUILD $(Build.BuildId)' workingDirectory: '$(System.DefaultWorkingDirectory)'
Task I’ve added to link the build number to file version information.
- filePath: powershell path to execute. Use
$(System.DefaultWorkingDirectory)if you want refer to cloned repository location.
- arguments: the argument to pass to script. Use
$(Build.BuildId)if you want refer to run number. Example: 1 = 1st run, 2 = 2nd run, 3 = 3rd run, and so on: in this way you can link a run number to a specific run pipeline to a specific file version.
This is related to “name” section above.
- workingDirectory: where the script has to be run
Predefined task: install NuGet tools to be able to restore NuGet packages
Predefined task: restore NuGet packages
Predefined task: build the solution.
You can use you custom-defined msbuild aruments to build the solution as you prefer.
Keep in mind a thing: if you want to “export” you build outside azure DevOps environment, you have to create at least a zip archive with build output. This is made by default by “
Task I’ve added to be able to download the build output to my local machine.
This will produce a build artifact which you can use into you Release pipeline, or simply download to your computer.
After run a build you’ll find a blue button on top-right corner, that allows you to download the build artifacts.