In some cases you may need to troubleshoot your azure devops tasks inside a job and get a more detailed output than the default. You can enable a detailed log output using predefined variables. In more detail you can use System.Debug and set it to true.
variables:
- name: System.Debug
value: true
By doing so you will get more debug messages as shown in the below screenshot.
With Azure devops you can create incredible automations. But in many cases you will need first to install the azure devops agent in order to run your tasks. Using the below powershell you can automate the installation of an azure devops agent.
New-Item "C:\agent" -itemType Directory
cd "C:\agent"
$url = "https://dev.azure.com/YOUR_ORG"
$token = "PAT_TOKEN"
$auth = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(":$token"))
$package = Invoke-RestMethod "$url/_apis/distributedtask/packages/agent?platform=win-x64&$`top=1" -Headers @{Authorization = "Basic $auth"}
$fileName = $package.value[0].fileName;
$downloadUrl = $package.value[0].downloadUrl;
Invoke-WebRequest -UseBasicParsing $downloadUrl -OutFile agent.zip
Expand-Archive -Force agent.zip -DestinationPath .
Remove-Item -Force agent.zip
.\config.cmd --unattended --replace --acceptTeeEula --work work --url https://dev.azure.com/YOUR_ORG --pool YOUR_POOL_NAME --auth pat --token $token --runAsService --runAsAutoLogon --windowsLogonAccount USER --windowsLogonPassword USER_PASSWORD
.\run.cmd
During the installation you may notice a problem for the powershell task to write on the log file.
Nevertheless the agent will be installed successfully.
Most times you will need to store logs for your azure resources in order to troubleshoot when things do not work as expected. Diagnostic settings for an app service can be enabled from the pane under Monitoring.
Then you should configure the diagnostic settings that will point which logs should be forwarded.
You can choose from the available categories shown below.
Lets now discover how we can enable diagnostic settings for an app service using terraform.
Create a file for example diagnostic_settings.tf and apply. The below configuration will enable all diagnostic settings categories.
resource "azurerm_monitor_diagnostic_setting" "diag_settings" {
name = "diag-settings"
target_resource_id = azurerm_windows_web_app.app_service1.id
log_analytics_workspace_id = local.log_analytics_workspace_id
log {
category = "AppServiceHTTPLogs"
enabled = true
retention_policy {
enabled = false
}
}
log {
category = "AppServiceConsoleLogs"
enabled = true
retention_policy {
enabled = false
}
}
log {
category = "AppServiceAppLogs"
enabled = true
retention_policy {
enabled = false
}
}
log {
category = "AppServiceAuditLogs"
enabled = true
retention_policy {
enabled = false
}
}
log {
category = "AppServiceIPSecAuditLogs"
enabled = true
retention_policy {
enabled = false
}
}
log {
category = "AppServicePlatformLogs"
enabled = true
retention_policy {
enabled = false
}
}
metric {
category = "AllMetrics"
retention_policy {
enabled = false
days = 30
}
}
}
You can also perform the same using a loop and a local variable in order to minimize code and make it more readable.
Assign a new variable inside your locals.tf file.
log_analytics_log_categories = ["AppServiceHTTPLogs", "AppServiceConsoleLogs","AppServiceAppLogs","AppServiceAuditLogs","AppServiceIPSecAuditLogs","AppServicePlatformLogs"]
Then perform terraform apply.
resource "azurerm_monitor_diagnostic_setting" "diag_settings" {
name = "diag-rule"
target_resource_id = azurerm_windows_web_app.app_service1.id
log_analytics_workspace_id = local.log_analytics_workspace_id
dynamic "log" {
iterator = entry
for_each = local.log_analytics_log_categories
content {
category = entry.value
enabled = true
retention_policy {
enabled = false
}
}
}
metric {
category = "AllMetrics"
retention_policy {
enabled = false
days = 30
}
}
}
After applying terraform all the settings will be enabled.
Continuous integration (CI) triggers cause a pipeline to run whenever you push an update to the specified branches or you push specified tags. Build in triggers can become a powerful tool for your build strategy and the most common scenarios will be explained using the examples below.
Continuous integration triggers:
Branches:
Those will trigger your pipeline when a new commit is performed on your branch. In the scenario below the pipeline will run if code is merged on your main branch or a branch starting from releases like release1, release-1 releases etc. Also the pipeline will not run if a push is commited on uat branch. This is excluded through the exclude keyword.
trigger:
branches:
include:
- main
- release/*
exclude:
- uat
Tags:
Those will trigger your pipeline only when a tag is pushed on your repository. Tags are bound with a commit on a git source control system. In the scenario below the pipeline will get triggered if a tag is pushed following the v.* regex like v.1 , v.something, v.2 etc. Also it will not run if the tag that is pushed starts with uat keyword for example uat-1 will not trigger the pipeline.
trigger:
tags:
include:
- v.*
exclude:
- uat*
Pull Requests:
pr keyword will trigger your pipeline if a pull request is created from a branch and the destination is the noted one. For example if you create a new pull request from mybranch to current branch then the pipeline will get triggered. The pipeline will not trigger if a pull request is created from any branch to uat branch as it is excluded.
trigger:
pr:
branches:
include:
- current
exclude:
- uat
One powerful tool that you can combine with your build strategy is paths. When you specify paths, you must explicitly specify branches to trigger on. You can’t trigger a pipeline with only a path filter; you must also have a branch filter, and the changed files that match the path filter must be from a branch that matches the branch filter.
Paths:
Using a path you specify a directory/folder which will trigger the build. For example you may want only to trigger a build when particular files are changed on your repository. In the below example the pipeline will get triggered if files inside the docs folder change for the branches master and releases*
trigger:
branches:
include:
- master
- releases/*
paths:
include:
- docs
exclude:
- docs/README.md
Microsoft documentation for build strategies:
