Merge Changes and Validate

As you Save your changes, your branch build will kick off. Let's validate our changes by checking what happens to our pipeline runs as we move to merge our changes into main.

Passing branch build

We should have a passing build, similar to previous builds. However, our conditional statements should only run the build and test tasks and skip the package and publish tasks. Additionally, notice the agent pool that was used for the build.

Now we are ready to merge changes from your branch into main using a pull request (PR).

Passing pull request build

Following proper practices with branching and merging with continuous integration, builds kickoff with each branch commit, PR, and merge. The PR build simulates a merge with the target to perform a preliminary build validation. Similar to the branch build, the PR build should not run the package and publish tasks.

When creating the pull request, make sure you update the target repository to your fork. By default, a forked repository will push changes back to the upstream (original) repository.

The ADO Dojo Sandbox project has branch policies to protect the main branch. All changes to main must come through a pull request, along with: - Linked work item - Approval by a reviewer (other than yourself) - No merge conflict - Passing PR build

Passing build on main branch

Because we added conditional statements in our pipeline, only main is packaging and publishing artifacts. Although we ran three pipeline runs (branch, PR, main), only one artifact was pushed to our Artifact Feed.

• Look at the Pipeline view on the recent main branch build and validate that all four tasks ran
• Look at your Artifacts feed and validate a recent app artifact has been published

Solution

If you had failing builds or if the pipeline did not execute as expected, compare your azure-pipelines.yml to the functioning code below.

Correct azure-pipelines.yml code

There were two variables vmssName and appArtifactName used from the variable group called VG-dojo-coaches, and one variable BuildConfiguration that was defined locally to the pipeline. This file also includes a displayName for each task that decorates the pipeline execution view with a label.

pool: $(vmssName)

variables:
  - group: VG-dojo-coaches

steps:
- task: DotNetCoreCLI@2
  inputs:
    command: 'build'
    arguments: '--configuration $(BuildConfiguration)'
  displayName: 'Build App'

- task: DotNetCoreCLI@2
  inputs:
    command: 'test'
    arguments: '--configuration $(BuildConfiguration) --no-build --no-restore'
  displayName: 'Unit Tests'

- task: DotNetCoreCLI@2
  condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')
  inputs:
    command: 'publish'
    publishWebProjects: true
    arguments: '--configuration Release --output $(Build.ArtifactStagingDirectory) --no-build --no-restore'
  displayName: 'Package Artifact'

- task: UniversalPackages@0
  condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')
  inputs:
    command: 'publish'
    publishDirectory: '$(Build.ArtifactStagingDirectory)'
    feedsToUsePublish: 'internal'
    vstsFeedPublish: 'c214cc40-9426-4e8f-8a0a-8e71c2a297fe/ed532ff1-b477-49de-b9ca-3790eb2fda1e'
    vstsFeedPackagePublish: $(appArtifactName)
    versionOption: 'patch'
  displayName: 'Publish to Feeds'