- \n
- hosted in Azure App Service<\/a> <\/li>\n
- your code in Azure Repos<\/a> <\/li>\n
- your CI pipeline in Azure Pipelines<\/a>.<\/li>\n<\/ul>\n
But what if your code is GitHub and your CI\/CD Pipeline is using Azure Pipelines<\/a>? Easy peasy. Just continue reading and I’ll show you what to do.<\/p>\n
Again, like that first blog post of mine, I’ll show the classic editor first because it’s prettier than a wall of YAML. But if you want the TLDR version, I’ll post the YAML for my CI pipeline at the end of the blog post.<\/p>\n
What Needs To Change?<\/h2>\n
Luckily, not much has to change. All you need to do is make two small tweaks.<\/p>\n
- \n
- Update the task,
Add Staging URL to PR Comment<\/code><\/li>\n- Decide what you want to happen with pull requests from forks.<\/li>\n<\/ul>\n
The first tweak is simple enough. Instead of using the Azure DevOps REST API<\/a> to add the staging URL to the PR comment, we will now use the GitHub REST API for Pull Requests<\/a>.<\/p>\n
For the second tweak, there are some security concerns to think about and a couple of different ways to work through them.<\/p>\n
Changing the task,
Add Staging URL to PR Comment<\/code><\/h2>\nLast time, by the time we were done, our CI pipeline looked like this with a task named
Add Staging URL to PR Comment<\/code>:<\/p>\n![\"Image](\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2020\/11\/c27768d13821c76d5dd1a7dccbbe25922b9cab97cc53e8911d494a218318facd.png?WT.mc_id=devops-10489-abewan\")
<\/a><\/p>\nOur inline code for that task looked like this:<\/p>\n
# Add PR comment with link to staging\necho \"Adding PR comment with link to staging environment...\"\nmessage=\"Created staging environment for PR - https:\/\/$(webApp.name)-staging-pr-\"$(System.PullRequest.PullRequestId)\".azurewebsites.net\/\"\necho \"message: $message\"\n\n# post message to PR using azure devops rest api\ncurl -i --user :$(azureDevOpsPAT) -H \"Content-Type: application\/json\" -H \"Accept: aon\" -X POST -d '{\"comments\": [{ \"parentCommentId\":0, \"content\": \"'\"$message\"'\", \"commentType\": 1}], \"status\": 1}' $(System.TeamFoundationCollectionUri)\/$(System.TeamProject)\/_apis\/git\/repositories\/$(Build.Repository.ID)\/pullRequests\/$(System.PullRequest.PullRequestId)\/threads?api-version=6.1-preview.1\n\necho \"Done adding PR comment with link to staging environment\"\n<\/code><\/pre>\nThis script uses the Azure DevOps REST API<\/a> to dynamically add a message with the staging url to the pull request comment in Azure Repos<\/a>.<\/p>\n
Since our code is in GitHub, we need to change the script so it uses the GitHub REST API for Pull Requests<\/a>. In order for that to work, GitHub recommends using an OAuth2 token sent in the authorization header<\/a>. The easiest way to do that is to create and use a GitHub personal access token (PAT).<\/p>\n
Generating a GitHub Personal Access Token<\/h3>\n
To create a PAT, log into GitHub and then from your picture in the upper right hand corner click Settings<\/p>\n
![\"Image](\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2020\/11\/9fcf546f73421355eae6b396f6148bbdf3dd0df3bdebfba92cc3d2b989a8227a.png?WT.mc_id=devops-10489-abewan\")
<\/a><\/p>\nDeveloper settings<\/p>\n
![\"Image](\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2020\/11\/9fe7b4bd0b7725a321632f1ad0fba84a622ab11fb57cb964df058e2f32790c75.png?WT.mc_id=devops-10489-abewan\")
<\/a><\/p>\nPersonal Access Token<\/p>\n
![\"Image](\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2020\/11\/6e3f39e857e42ae5154e810169473c7ee609a9bf2ec72430a29e92127f03079f.png?WT.mc_id=devops-10489-abewan\")
<\/a><\/p>\nGenerate new token<\/p>\n
![\"Image](\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2020\/11\/80235ac33bcf1dc1c8be325bab21ca8fd455260bc7fd53c5b8e00ed40b00f89b.png?WT.mc_id=devops-10489-abewan\")
<\/a><\/p>\nAnd from here, you can create your PAT. Make sure you save this value because once you leave this page, you’ll never get this value again!<\/p>\n
Create New Task,
Add Staging URL to PR Comment<\/code>, To Add Message To GitHub PR<\/h3>\nWe’re gonna be using this GitHub PAT in our pipeline so let’s add this as a secure pipeline variable<\/a>.<\/p>\n
![\"Image](\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2020\/11\/0e848084dc5ceb6e81d0ab91f25e9e9d0c02e47acb268e26bbae8a4b5b3460f7.png?WT.mc_id=devops-10489-abewan\")
<\/a><\/p>\nNext, I delete the bash task named
Add Staging URL to PR Comment<\/code> and in its place I add a powershell task. Why powershell? No reason. I just wanted to show it really doesn’t matter what shell you use. Use what works for you!<\/p>\nThis powershell task should only run if all the previous tasks were successful and the build was triggered by a pull request. So I set Control Option > Run this task to<\/p>\n
Custom conditions\n<\/code><\/pre>\nand I set Control Option > Custom condition to<\/p>\n
and(succeeded(), eq(variables['Build.Reason'], 'PullRequest'))\n<\/code><\/pre>\n![\"Image](\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2020\/11\/e6f619b025d482b720a78c6c9caf045d943129c2f51c60d6e36e5dc1cb533220.png?WT.mc_id=devops-10489-abewan\")
<\/a><\/p>\nNext, I give this task a better name<\/p>\n
Add Staging URL to PR Comment\n<\/code><\/pre>\nselect<\/p>\n
Inline\n<\/code><\/pre>\nand in the Script textbox, I add the powershell script which uses the GitHub REST API for Pull Requests<\/a> to add the comment to the pull request.<\/p>\n
Write-Output \"Adding comment to GitHub pull request via rest api...\"\n\n# create GitHub REST api URL\n$prNumber = $(System.PullRequest.PullRequestNumber)\n$prInfoUrl = 'https:\/\/api.github.com\/repos\/abelsquidhead\/TestPRTriggerRepo\/pulls\/' + $prNumber\n$response = Invoke-RestMethod -URI $prInfoUrl\n$commentUrl = $response.issue_url + '\/comments'\n\n# add comment to the PR in GitHub using GitHub REST api\n$authorizationHeaderValue = \"token \" + $env:GITHUB_OATH_TOKEN\n$message = \"Created staging environment for PR - https:\/\/abeltestwebapp-staging-pr-\" + $prNumber + \".azurewebsites.net\/\"\n$body = '{\"body\":\"' + $message + '\"}'\nInvoke-RestMethod -Method 'Post' -Uri $commentUrl -Headers @{\"Authorization\" = $authorizationHeaderValue} -Body $body\nWrite-Output \"Added staging url as comment to GH pull request\"\n<\/code><\/pre>\n![\"Image](\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2020\/11\/2530fb1c6910929b09832e5808417e93dc3ca6be1e718cb523c99a883a8218ac.png?WT.mc_id=devops-10489-abewan\")
<\/a><\/p>\nNotice in the inline script, I’m adding authentication through my header<\/p>\n
$authorizationHeaderValue = \"token \" + $env:GITHUB_OATH_TOKEN\n<\/code><\/pre>\nI’m passing my GitHub PAT in as an environment variable so I’ll need to set it under Environment Variables:<\/p>\n
![\"Image](\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2020\/11\/72d6bc27ed4179ad63795e18a5c126dd50e9e5e02ce777301e402101f10bc7f8.png\")
<\/a><\/p>\nEnabling CI for pull requests from GitHub<\/h2>\n
To enable this CI build to run on every pull request, go Triggers > Pull request validation and click Enable pull request validation<\/p>\n
![\"Image](\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2020\/11\/f4e99f3aa912897649d0fa3e634aeba3ca7b76b43d3e5b13dd6a21a2098fffb7.png?WT.mc_id=devops-10489-abewan\")
<\/a><\/p>\nNext we need to decide if we want this CI build to run on every pull request, including Forks.<\/p>\n
Security Considerations for Forks and CI Builds<\/h3>\n
If we want this PR workflow to run on all pull requests including forks, just click on
Build pull requests from forks of this repository<\/code> and checkMake secrets available to builds of forks<\/code>. That’s because our CI pipeline uses secrets.<\/p>\n![\"Image](\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2020\/11\/08bc8a44c26286b31ae33eba685c011a2f51ced5ab97fb3bf7812e4a4ae8ba5b.png?WT.mc_id=devops-10489-abewan\")
<\/a><\/p>\nHowever, before you do this, you need to think about security. Forks from GitHub can really come from anywhere! They can even come from non trusted people, or even worse, malicious people. If all pull requests including PR’s from forks automatically run this CI pipeline, some simple changes to unit tests or to other scripts could easily leak your secrets (most of my ci pipelines automatically run my unit tests). Yikes!!!!<\/p>\n
One thing you can do is tweak your CI pipeline so all it does is compile, run tests and package everything up. And then create a CD pipeline that only<\/strong> gets triggered after a successful CI run that does the provision PR staging slot, deploy to slot and add staging slot URL to PR comment. Triggering one pipeline after another<\/a> is super useful. This would make leaking secrets a tougher since now, only your CD pipeline uses secrets. I can’t just make malicious changes to unit tests that will automatically get run. However, I could still make some malicious changes in the code itself and secrets could still be leaked. That might be good enough though.<\/p>\n
To be the most secure, don’t automatically execute this workflow from forks. Manually trigger the CI for PR’s from forks. This will give you the opportunity to review the code before automatically triggering the build. Read this for more details on security considerations with forks<\/a>.<\/p>\n
YAML Time<\/h2>\n
See, I told you. Easy peasy. So what does all this look like in YAML?<\/p>\n
trigger:\n- master\n\npool:\n vmImage: 'ubuntu-latest'\n\nvariables:\n servicePrincipal.name: 'http:\/\/AbelDeployDemoBackupPrincipal'\n servicePrincipal.tenant: '72f988bf-86f1-41af-91ab-2d7cd011db47'\n webApp.name: 'PRWorkflowBlogAppService'\n webApp.resourceGroup: 'PRWorkflowBlog'\n BuildConfiguration: 'release'\n\nsteps:\n\n# Use .NET core 5 sdk\n- task: UseDotNet@2\n displayName: 'Use .NET Core 5 SDK'\n inputs:\n version: 5.x\n includePreviewVersions: true\n\n# Build .net core project \n- task: DotNetCoreCLI@2\n displayName: Build\n inputs:\n projects: '$(Parameters.RestoreBuildProjects)'\n arguments: '--configuration $(BuildConfiguration)'\n\n# Restore project\n- task: DotNetCoreCLI@2\n displayName: Build\n inputs:\n projects: '$(Parameters.RestoreBuildProjects)'\n arguments: '--configuration $(BuildConfiguration)'\n\n# Run unit tests\n- task: DotNetCoreCLI@2\n displayName: Test\n inputs:\n command: test\n projects: '$(Parameters.TestProjects)'\n arguments: '--configuration $(BuildConfiguration)'\n\n# Publish .net core app to staging directory\n- task: DotNetCoreCLI@2\n displayName: Publish\n inputs:\n command: publish\n publishWebProjects: True\n arguments: '-r win-x64 --self-contained true --configuration $(BuildConfiguration) --output $(build.artifactstagingdirectory)'\n\n# Publish build bits as build artifact\n- task: PublishBuildArtifacts@1\n displayName: 'Publish Artifact'\n inputs:\n PathtoPublish: '$(build.artifactstagingdirectory)'\n condition: succeededOrFailed()\n\n# Create CI Staging Slot for PR\n- bash: |\n # Login to Azure using service principal\n echo 'Logging into Azure with service principal...'\n az login \\\n --service-principal \\\n --username $(servicePrincipal.name) \\\n --tenant $(servicePrincipal.tenant) \\\n --password $SERVICE_PRINCIPAL_PASSWORD\n echo 'Logged into Azure'\n echo ''\n\n # Create staging slot for PR\n echo 'Creating staging slot for PR...'\n az webapp deployment slot create \\\n --name $(webApp.name) \\\n --resource-group $(webApp.resourceGroup) \\\n --slot staging-pr-$(System.PullRequest.PullRequestId)\n echo \"Created staging slot for PR \" $(System.PullRequest.PullRequestId)\n\n displayName: 'Create CI Staging Slot For PR'\n condition: and(succeeded(), eq(variables['Build.Reason'], 'PullRequest'))\n env:\n SERVICE_PRINCIPAL_PASSWORD: $(servicePrincipal.password)\n\n# Add staging URL to PR comment\nsteps:\n- powershell: |\n Write-Output \"Adding comment to GitHub pull request via rest api...\"\n\n # create GitHub REST api URL\n $prNumber = $(System.PullRequest.PullRequestNumber)\n $prInfoUrl = 'https:\/\/api.github.com\/repos\/abelsquidhead\/TestPRTriggerRepo\/pulls\/' + $prNumber\n $response = Invoke-RestMethod -URI $prInfoUrl\n $commentUrl = $response.issue_url + '\/comments'\n\n # add comment to the PR in GitHub using GitHub REST api\n $authorizationHeaderValue = \"token \" + $env:GITHUB_OATH_TOKEN\n $message = \"Created staging environment for PR - https:\/\/abeltestwebapp-staging-pr-\" + $prNumber + \".azurewebsites.net\/\"\n $body = '{\"body\":\"' + $message + '\"}'\n Invoke-RestMethod -Method 'Post' -Uri $commentUrl -Headers @{\"Authorization\" = $authorizationHeaderValue} -Body $body\n Write-Output \"Added staging url as comment to GH pull request\"\n displayName: 'Write Staging URL to PR as Comment'\n condition: and(succeeded(), eq(variables['Build.Reason'], 'PullRequest'))\n env:\n GITHUB_OATH_TOKEN: $(github.oathToken)\n\n# Deploy build to staging environment\n- task: AzureRmWebAppDeployment@4\n displayName: 'Deploy to PR Staging'\n inputs:\n ConnectionType: 'AzureRM'\n azureSubscription: 'AbelDemosSubscription(2f42eaaf-1883-462f-a04f-a1d88fa6fd44)'\n appType: 'webApp'\n WebAppName: 'PRWorkflowBlogAppService'\n deployToSlotOrASE: true\n ResourceGroupName: 'PRWorkflowBlog'\n SlotName: 'staging-pr-$(System.PullRequest.PullRequestId)'\n packageForLinux: '$(System.DefaultWorkingDirectory)\/**\/netlandingpage.zip'\n enableCustomDeployment: true\n DeploymentType: 'webDeploy'\n RemoveAdditionalFilesFlag: true\n ExcludeFilesFromAppDataFlag: false\n condition: and(succeeded(), eq(variables['Build.Reason'], 'PullRequest'))\n\n\n\n\n# Delete staging slot\n- bash: |\n # PR Closed, changes merged to main\n echo 'PR close, changes merged to main'\n\n # get the source version message\n sourceVersionMessage=\"$(Build.SourceVersionMessage)\"\n echo 'build source version message: ' $sourceVersionMessage\n\n # parse the PR number from the source version message\n prNumber=$(echo $sourceVersionMessage| sed -r 's\/^([^.]+).*$\/\\1\/; s\/^[^0-9]*([0-9]+).*$\/\\1\/')\n echo 'prNumber: ' $prNumber\n\n # Login to Azure using service principal\n echo 'Logging into Azure with service principal...'\n az login \\\n --service-principal \\\n --username $(servicePrincipal.name) \\\n --tenant $(servicePrincipal.tenant) \\\n --password $SERVICE_PRINCIPAL_PASSWORD\n echo 'Logged into Azure'\n echo ''\n\n # Delete PR staging slot\n echo 'Deleting staging slot for PR ' $prNumber '...'\n az webapp deployment slot delete \\\n --name $(webApp.name) \\\n --resource-group $(webApp.resourceGroup) \\\n --slot staging-pr-$prNumber\n echo 'Deleted slot for PR ' $prNumber\n displayName: 'Delete Staging Slot For PR'\n condition: and(succeeded(), startsWith(variables['Build.SourceVersionMessage'], 'Merged PR '))\n env:\n SERVICE_PRINCIPAL_PASSWORD: $(servicePrincipal.password)\n<\/code><\/pre>\nTo set the trigger, go to Edit<\/p>\n
![\"Image](\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2020\/11\/8cd3440fbb1a4110872fb601fffe4714f0aed80cfbd97d9deb0229f4fb4673cd.png?WT.mc_id=devops-10489-abewan\")
<\/a><\/p>\n3 virticle dots > Triggers<\/p>\n
![\"Image](\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2020\/11\/df44bfbb03b243eee5aeeae76c1ee81e55120225560ecfb556fe16e6c9f9db1f.png?WT.mc_id=devops-10489-abewan\")
<\/a><\/p>\nPull request validation<\/p>\n
![\"Image](\"https:\/\/devblogs.microsoft.com\/devops\/wp-content\/uploads\/sites\/6\/2020\/11\/24631782cd4c8999f63a53e293b6458d6812099c983108e464614850fb85bdb2.png?WT.mc_id=devops-10489-abewan\")
<\/a><\/p>\nRemember, give some serious consideration to how you want forks to be handled. There are definitely security concerns to be thought through.<\/p>\n
Conclusion<\/h2>\n
The Pull Request workflow used by Static Web Apps<\/a> is sick. In part 1 of this series (Static Web App PR Workflow for Azure App Service)<\/a>, I showed how to do this same workflow for Azure App Service<\/a>, Azure Repos<\/a> and Azure Pipelines<\/a>. For this blog, I showed how to modify that pipeline if your code sits in GitHub instead of Azure Repos<\/a>.<\/p>\n
The changes were pretty simple. Just swap out the Azure DevOps REST API<\/a> calls to write a pull request comment for the GitHub REST API for Pull Requests<\/a>.<\/p>\n
Because our code now sits in GitHub, some extra security considerations should be given to pull requests coming from Forks. But beyond that, it’s easy enough to tweak our CI definition in Azure Pipelines to handle having our code in GitHub.<\/p>\n
Related Links<\/h2>\n
(Static Web App PR Workflow for Azure App Service)<\/a><\/p>\n
Static Web Apps<\/a><\/p>\n
GitHub Actions<\/a><\/p>\n
Azure App Service<\/a><\/p>\n
Azure Repos<\/a><\/p>\n
Azure Pipelines<\/a><\/p>\n
CI\/CD GitHub Repositories with Azure Pipelines<\/a><\/p>\n
.NET Core<\/a><\/p>\n
Branch Policies<\/a><\/p>\n
Staging with Deployment Slots<\/a><\/p>\n
Azure CLI<\/a><\/p>\n
Login to Azure<\/a><\/p>\n
Creating Slots with Azure CLI<\/a><\/p>\n
Azure Service Principal<\/a><\/p>\n
Pipeline Built In Variables<\/a><\/p>\n
Azure DevOps REST API<\/a><\/p>\n
Write Comment To Pull Request<\/a><\/p>\n
Azure DevOps PAT<\/a><\/p>\n
Azure DevOps Web Hooks<\/a><\/p>\n
Azure Functions<\/a><\/p>\n
Delete Slot with the Azure CLI<\/a><\/p>\n
Using Secret Variables In YML Pipelines<\/a><\/p>\n
GitHub REST API for Pull Requests<\/a><\/p>\n
- Decide what you want to happen with pull requests from forks.<\/li>\n<\/ul>\n
- your code in Azure Repos<\/a> <\/li>\n