Using GitLab as source control provider for Azure Automation

Using GitLab as source control provider for Azure Automation

When you want to integrate source control in Azure Automation, you’ll quickly notice that you can only choose GitHub as source provider, with Visual Studio Online (TFS) coming soon. There are Runbooks available to configure Visual Studio Team Services as source provider. However, there is no such solution available (yet) for GitLab. That changes today!

In my very first blog post I’ll describe how to set up GitLab as source provider for Azure Automation, using the Sync-GitLab Azure Automation runbook that I have published to the TechNet Script Center. Considering that you have a GitLab repository that you want to use as a source for Azure Automation runbooks.

So how does that work?

In short, changes to the master branch in a GitLab repository will trigger an Azure Automation runbook using a webhook. The runbook will compare the changes in that repository between the most recent commit and the last commit since the runbook’s last runtime, based on their Secure Hash Algorithm (SHA) values. All changes in GitLab (new, updated or removed scripts) will be reflected in the Azure Automation account.

All PowerShell Scripts (.ps1) files in the root of the GitLab repository will use their scripts base name as Runbook name in the Azure Automation account.

Prerequisites

  • Create a variable asset in the Azure Automation account, which includes the SHA value of the most recent commit in the master branch.

    Note: If you intend to sync multiple GitLab repositories to a single Automation Account, or initiate the Sync-GitLab Runbook from a single Azure Automation account to deploy changes to multiple Azure Automation accounts, it is advised to include the GitLab Project ID and Azure Automation account name in the Variable asset’s name. For instance: GitLabShaProjectID2018-AUT-ACC-01.

Configure

Azure Automation webhook

To use GitLab as source provider, a webhook needs to be created to trigger the Sync-GitLab runbook when changes are made to the GitLab repository.

  • Navigate to the Sync-GitLab runbook in your Azure Automation account and add a Webhook;
    • Webhook
      • Name: I will be using the naming format: Sync-GitLab%ProjectID%-%AutomationAccountName%, which results in Sync-GitLab1102-SRDN-AUT-TST. This helps to identify the correct webhooks quickly if you sync multiple repositories (to one or more Automation Accounts);
      • Expires: Modify and make note of the expiry date. If the Webhook expires, changes will no longer be synchronised;
      • URL: Copy the URL and save it for later use. After creating the webhook its URL can no longer be viewed;
    • Parameters
      • ResourceGroupName: Enter the name of the ResourceGroup containing the Automation Account;
      • AutomationAccountName: Enter the name of the Automation Account where GitLab changes will be synced to;
      • GitLabServer: Enter the domain of the GitLab server. For example: gitlab.domain.com;
      • AccessTokenVariableName: Enter the name of the variable asset containing the Personal Access Token;
      • LastShaVariableName: Enter the name of the variable asset containing the SHA value of a commit;
      • ProjectID: Enter the Project ID containing the GitLab repository that will be synced;

GitLab integration

To let Azure Automation know that changes to the repository were made, you will integrate the webhook with the GitLab repository, which triggers the runbook on Push and Merge Request events.

  • Navigate to the GitLab repository > Settings > Integrations.
  • Add a webhook with the following values:
    • URL: Enter the Webhook URL;
    • Triggers:
      • Push events: True;
      • Merge Request events: True;
    • Enable SSL verification: True

Result

Now that you have configured GitLab as source provider for your Automation Account, let’s go ahead and check out the solution!

  • Push a PowerShell script (.ps1) to the GitLab repository’s master branch (Push event) or create a new branch including the PowerShell script and accept the Merge request (Merge Request event);
  • Verify that an Automation Job was created for the Sync-GitLab runbook;
  • Review the output of the Sync-GitLab runbook;
  • Validate that a new Azure Automation runbook was created, that contains the content of your PowerShell script.

 

4 thoughts on “Using GitLab as source control provider for Azure Automation

  1. Nice blog. Good topic – Workplace automation in the cloud. Very contemporary and certainly of great importance in the future of automation.

    Keep going.

  2. I am Receiving the following Error
    “Failed to obtain the current SHA of the master branch”

    I have tried a couple of times with a new SHA value of the latest push. (theorectically it is 1 push behind as the next push that triggers the run book is a new SHA?)

    any ideas how i can investigate this

    1. Hi Robbie,

      That error correspondents to the retrieval of the current SHA value of the master branch, obtained using the Invoke-RestMethod cmdlet on line 103 of the script.

      It could be that the value provided in the $GitLabServer, $ProjectId or $AccessToken variable is invalid. What was the StatusCode and StatusDescription returned in the error?

      Please try and execute below commands. Either declare the variables or replace them with your own values, and check if a SHA value is returned.

      $CurrentMasterUri = "https://$GitLabServer/api/v4/projects/$ProjectId/repository/commits/master?private_token=$AccessToken"
      $CurrentMasterResponse = Invoke-RestMethod -Method "GET" -Uri $CurrentMasterUri
      $CurrentMasterResponse.id

Leave a Reply

Your email address will not be published. Required fields are marked *