Maintenance Jobs for build agents explained – Azure DevOps

When you need to scale up your infrastructure, you should enable as much automated options for maintenance as possible. One of the available options for devops agents are included under Organization Settings -> Agent pools -> Settings.

There you can define automated procedures for cleanup on your agent pools.

In my setup, I changed the days to keep unused working directories to 20.

The working directories of the agent are some folders with specific numbers inside C:\agent\work.

Every time a new build is initiated a new folder for this specific run is created. If the same pipeline runs more than one time, then the same working directory will be kept and the files will get overridden. For example lets say my pipeline A is bind to the folder 5. Then every time the pipeline A runs, then the folder 5 will be used for the sources (git repositories) builds, artifacts etc. All previous data hosted there will be deleted and written again.

The maintenance jobs will remove any directories than are not used for x period of days. In my example I had set up 20 days for that task.

You can configure agent pools to periodically clean up stale working directories and repositories. This should reduce the potential for the agents to run out of disk space. Maintenance jobs are configured at the project collection or organization level in agent pool settings.

You can check your history under Organization Settings -> Agent pools -> Maintenance History.

You can also download the log and figure out how much data have been deleted.

Maintenance jobs:

Create and manage agent pools – Azure Pipelines | Microsoft Docs

Video tutorial on YouTube:

Build pipeline on tag push – Azure DevOps build triggers

There are multiple ways to define your continuous integration trigger on a pipeline depending on your needs. One common approach is to trigger a build whenever a new merge or push is done on your branch.

For example with the below notation you could trigger a new build every time a new push is merged on the uat branch.

trigger:
- uat

Another approach could be the pull request. Every time a new pull request is created for a specific branch your build could be initiated. In order to accomplish that you should use the pr keyword.

The below example will trigger when a new pull request is created and the merge destination is main branch. This approach could help you identify if the code of a specific feature/branch actually builds and can be merged on your main branch.

pr:
  branches:
    include:
    - main

Another approach is the tags functionality. You could run a build only if a specific tag is pushed along with the commit.

The below example will only build when the tag release.* is pushed on the branch on which the pipeline is located.

trigger:
  tags:
    include:
    - release.*

Some tags that could trigger my build are: release.v1 , release.master, release.v2

In order to push a tag on your branch using cmd you should

git add .
git commit -m "commit message"
git tag mytag
git push --tags

Then on tags section of your repository you can locate your new tag.

Documentation of triggers for Azure pipelines:

https://docs.microsoft.com/en-us/azure/devops/pipelines/yaml-schema/trigger?view=azure-pipelines

Video tutorial on YouTube:

CI/CD build pipeline for .NET solutions using Cake2 – Azure Devops

In a previous article Build .NET solutions/projects using cake 2 I described how you can build a .NET solution using cake 2. In this tutorial I will explain how you can create your continuous integration pipeline to build your projects automatically with cake 2 and a build agent.

You should first store your project on a git repository. For the purposes of this demo I will choose Azure Devops. I first clone the repository and add the appropriate code. Then I push back to the remote.

Git commands:

git add
git commit -m "added code"
git push

Then under main branch the src folder will be located. In this folder the code is placed.

The second step is to create the pipeline and store it in the repository. Press new pipeline and then select your Azure Repos Git.

Then choose the starter pipeline on which we will add some tasks.

The code for the pipeline is just a simple powershell script that will execute the cake build command as we examined on the previous article.

trigger:
- main

pool:
  vmImage: ubuntu-latest
steps:

- task: PowerShell@2
  displayName: Build step using cake
  inputs:
    targetType: 'inline'
    script: 'dotnet cake'
    workingDirectory: '$(Build.SourcesDirectory	)/src/'

When I tried to build my application although the procedure started, I got an error about the targeting SDK.

You can resolve this by specifying your requested DotNet version.

- task: UseDotNet@2
  displayName: Use .NET 6
  inputs:
    version: '6.0.x'
    includePreviewVersions: true

Finally the build will be successful.

The final pipeline will be the below:

trigger:
- none

pr: none

pool:
  vmImage: ubuntu-latest
steps:

- task: PowerShell@2
  displayName: install cake tool
  inputs:
    targetType: 'inline'
    script: 'dotnet tool install Cake.Tool --version 2.0.0 --global'

- task: UseDotNet@2
  displayName: Use .NET 6
  inputs:
    version: '6.0.x'
    includePreviewVersions: true

- task: PowerShell@2
  displayName: Build step using cake
  inputs:
    targetType: 'inline'
    script: 'dotnet cake'
    workingDirectory: '$(Build.SourcesDirectory)/src/'

Build .NET solutions/projects using cake 2

Cake is a powerful tool that implements build functionality for various .NET solutions. It can extend your build with custom parameters and values that you want to reference on a CI/CD pipeline or in your metadata. In this article I will demonstrate how to use cake in order to build your .NET solution.

First create a Console App or another .NET solution that you want to build.

create a new console application

For this demonstration I will use the default template that is provided from cake website. You should rename and point to your solution name, in my case the solution is named ConsoleApp1.

The default build script includes three tasks.

  • The first one cleans output of previous builds.
  • The second one will build your application
  • The third will run .net tests.

In the build script provided below, I have provided as configuration Debug. You can change this value on the configuration line.

var target = Argument("target", "Build");
var configuration = Argument("configuration", "Debug");

//////////////////////////////////////////////////////////////////////
// TASKS
//////////////////////////////////////////////////////////////////////


Information("Beginning cleaning application.....");
Task("Clean")
    .WithCriteria(c => HasArgument("rebuild"))
    .Does(() =>
{
    CleanDirectory($"./bin/{configuration}");
});

Information("Beginning building application.....");

Task("Build")
    .IsDependentOn("Clean")
    .Does(() =>
{
    DotNetCoreBuild("./ConsoleApp1.sln", new DotNetCoreBuildSettings
    {
        Configuration = configuration,
    });
});


Information("DotNetCoreTest task .....");

Task("Test")
    .IsDependentOn("Build")
    .Does(() =>
{
    DotNetCoreTest("./ConsoleApp1.sln", new DotNetCoreTestSettings
    {
        Configuration = configuration,
        NoBuild = true,
    });
});

//////////////////////////////////////////////////////////////////////
// EXECUTION
//////////////////////////////////////////////////////////////////////

RunTarget(target);

In order to build you should place the above file on your solution directory with the name build.cake. Then you will have to run dotnet cake and the build will run.

build output

https://cakebuild.net/