You have installed azure build agent on host machine and jobs are running fine. Now you want to control the context where the job is run then container jobs are best suited to have that control. As container jobs will run in containers providing isolation from host, it allows you to control and use specific versions of tools and dependencies. This way it requires less initial setup on host where agent runs and less infrastructure to maintain.

Note: The container jobs will not work if build agent itself is running in container.

In this article you will see how to build and test a simple application written in GoLang.

Download hello-world.go app code.

The repo includes azure-pipelines.yml

trigger:
- main


jobs:
- job: BuildAndTest
  workspace:
    clean: all
  pool:
    vmImage: Ubuntu-latest

  container: golang:1.16
  steps:
  - task: Go@0
    displayName: "Go Get"
    inputs:
      command: 'get'
      arguments: '-d'
      workingDirectory: '$(System.DefaultWorkingDirectory)'
  - task: Go@0
    displayName: "Go Build"
    inputs:
      command: 'build'
      workingDirectory: '$(System.DefaultWorkingDirectory)'
  - task: Go@0
    displayName: 'Go Test'
    inputs:
      command: 'test'
      arguments: './...'
  - task: CopyFiles@2
    displayName: "Copy files to ArtifactStaging"
    inputs:
      TargetFolder: '$(Build.ArtifactStagingDirectory)'
  - task: PublishBuildArtifacts@1
    displayName: "Publish Artifact"
    inputs:
       artifactName: drop

The build pipeline runs within golang container. The container job is run on Microsoft hosted build agent (Ubuntu). Drawback of using MS hosted build agent is that it will download the golang image every time before running it as a container. If this is run on self hosted build agent then it will download the image once only.

Reference:

https://docs.microsoft.com/en-us/azure/devops/pipelines/process/container-phases?view=azure-devops

https://docs.microsoft.com/en-us/azure/devops/pipelines/ecosystems/go?view=azure-devops&tabs=go-current