Triggering Azure Pipelines with an offline artefact repository

This blog post is part of a series of posts covering the challenges adopting the Azure DevOps SaaS offering in highly regulated industries. The second post covered how we can leverage Azure Pipelines with an offline source repository. Make sure you go through the first two posts in this series to ensure you have all the background behind the concepts described in this post.

In this post we will build on top of what we learned in the previous posts to enable enterprises to kick off their Continuous Delivery process based on changes to a Nexus Repository Manager v3 Repository.

High-level the connectivity for this scenario would look something like the following.

Pre-requisites

• Windows or Linux based Azure DevOps Self-hosted Agent Pool.
• Nexus Repository Manager Repository

High-level Steps

1. Create a new "Incoming Webhook" service connection, this is a new Service Connection Type which will be introduced which allows us to define two important pieces of information.
   • HTTP Header - the name of the HTTP Header in the request which contains the payload hash value for request verification. In the case of the Nexus Repository Manager web hook request the header will be "X-Nexus-Webhook-Signature".
   • Secret - the shared secret which is used to compute the payload hash used for verification of the incoming request.
     
2. Setup our Azure Pipeline for CD, this Pipeline will be triggered each time Azure DevOps receives a request for the incoming web hook endpoint. I'm using the Pipeline tasks provided by the "Sonatype Nexus Repository Release Artifact" extension to download the Nexus artefact from the repository. I'm also filtering the incoming Web Hook requests based on the source Nexus Repository & leveraging Pipeline parameters to access data related to the incoming request payload. Using these parameters we can identify the Nexus Component co-ordinates (Group, Name, Version etc). This Azure Pipeline could be extended to deploy artefacts which are retrieved from Nexus.

   trigger: none
   pool: SelfHostedAgentPool
   
   resources:
     webhooks:
       - webhook: nexusrepotrigger
         connection: nexus-repo-trigger
         filters:
           - path: repositoryName
             value: maven-releases
           - path: action
             value: CREATED
   
   steps:
   - checkout: none
   - task: DownloadArtifactsNexusMavenRepositoryV3@3
     displayName: 'Download Nexus Maven Repository v3 Artefact'
     inputs:
       NexusConnection: 'private-nexus'
       RepositoryId: ${{ parameters.nexusrepotrigger.repositoryName}}
       GroupId: ${{ parameters.nexusrepotrigger.component.group}}
       ArtifactId: ${{ parameters.nexusrepotrigger.component.name}}
       BaseVersion: ${{ parameters.nexusrepotrigger.component.version}}
       Packaging: jar
   

3. Setup a web hook on the Nexus Repository Manager repository which will trigger the CD pipeline, this can be done via the Nexus Repository Manager Admin Interface. See the following link for instructions on how to Add Web hook Repository Capability.
   • Request Url - "https://dev.azure.com/**[Organization]**/_apis/public/distributedtask/webhooks/[Azure DevOps Incoming WebHook Name]?api-version=6.0-preview"
   • Secret - Provide the same value used for the Incoming Webhook Azure DevOps Service Connection
   • Event Type - Select either Asset or Component its also possible to select both. For sake of this scenario select only component events.
     
4. Developers would create & manage their YAML Pipeline definitions as normal in the Azure Pipelines UI and these would be stored in an Azure Repo Git repository.
5. When a new component is uploaded to the Nexus Repository, the Repository webhook will be triggered.
6. The Azure Pipeline will be triggered each time the incoming web hook resource is requested, based on our Pipeline definition the first thing that will happen is that the artefact will be downloaded onto the Agent.
   
   and we can see that the artefact was successfully downloaded
   

Once this feature becomes available in Public Preview you will be able to try this out in your Azure DevOps Organization.