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.
- Requires GitLab API v4, which is the preferred version to be used and is included since GitLab 9.0;
- Import the AzureRM.profile (version 3.x or higher) PowerShell Module in the Automation Account;
- Import the Sync-GitLab Azure Automation runbook in the Azure Automation account, which is available as Azure Automation source control integration with GitLab in the Runbook Center.
- A valid Azure Run As Account needs to be present in the Azure Automation account;
- To preserve a 1-to-1 relationship between the GitLab repository and the Azure Automation account, all PowerShell scripts (.ps1) files need to be put in the root of the repository;
- Make note of the GitLab Project ID, which is located in the General Project Settings;
- Create an encrypted variable asset in the Azure Automation account, which includes your Personal Access Token to authenticate with the GitLab API;
- 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.
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;
- 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;
- 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;
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;
- Push events: True;
- Merge Request events: True;
- Enable SSL verification: True
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.
10 thoughts on “Using GitLab as source control provider for Azure Automation”
Nice blog. Good topic – Workplace automation in the cloud. Very contemporary and certainly of great importance in the future of automation.
Thanks jrv, much appreciated!
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
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
I would like to warn you about an issue I’ve got actually with the deployment of a webhook in automation. The button “Add a webhook” is grey and I can’t click on it. I use the very last version of Azure with my company and also tried with a personal account and the issue is the same. Do you know why the option to create a webhook is unavailable ?
Have you ‘Published’ the Runbook, or is it still in a ‘New’ state? You can only add a Webhook when the Runbook is published.
It’s really very informative and helpful. Thank you for sharing such an amazing information. Besides this every thing is clear and best in this article. Keep it up.
So just wanted to make sure that GitLab will not be visable under “Source Control” option for Automation Account?
Also if I just want to sync GitLab repository with Automation Account, instead executing it – I would have to modify PS script – right?
That’s correct, GitLab will not be visible under Source Control. The Runbook is a custom sync solution. You will need to execute the Runbook to sync your GitLab repository with the Automation Account.