I have a problem regarding Azure DevOps and release management. First a little background - we use visualstudio.com along with build agents, release agents (running on different environment VMs) to manage our CI, builds, and releases. I am trying to troubleshoot logging on my non-development servers and have traced the problem back to missing elements in my appsettings.json file. When I log into my production VMs and look at the appsetings.json file, I found that my Logging section looked like this:
"Logging": {
"IncludeScopes": false,
"LogLevel": {
"Default": "Information"
}
},
While within my appsettings.json file within my build artifacts (the website .zip file) looks like this:
"Logging": {
"IncludeScopes": false,
"LogLevel": {
"Default": "Debug",
"System": "Information",
"Microsoft": "Information"
}
},
My logging issues are fixed when I go on the server and change the appsettings.json Logging section to match what is should be according to the appsettings in the build .zip.
My question is - what is it within the Azure DevOps release pipeline (formerly VSTS) that is changing the appsettings.json Logging section? I have verified that my release definition has no variable substitutions for the logging section.
This looks very much like your build is taking the wrong sources. Is it possible that the wrong appsettings.json that you're seeing reflects an outdated version? I don't know why this happens, but I've seen this a couple of times in the past both with Git and TFVC.
If this is the issue, then cleanup your agent working folders or select (once or permanantly) cleanup in the build definition:
Found the problem (and its a silly one). The problem ended being multiple declarations of the Logging section in the appsettings.json file. The declaration at the bottom of the file has:
"Logging": {
"IncludeScopes": false,
"LogLevel": {
"Default": "Information"
}
},
which would match whats getting deployed.
Related
i am trying to migrate a project from one organization project to another Project .
From Source Azure Devops Project to Target DEvops project.
What should be the ReflectedWorkItemIDFieldName: ?
i tried changing it to :
Custom.ReflectedWorkItemId
ReflectedWorkItemId
ProcessName.ReflectedWorkItemId
GlobalWit.ReflectedWorkItemId
but its does not helps. Please help me
error
Microsoft.TeamFoundation.WorkItemTracking.Client.ValidationException: TF51005: The query references a field that does not exist. The error is caused by «[Custom.ReflectedWorkItemId]»
===
my config file
"Source": {
"Collection": "https://dev.azure.com/somegDevOps/",
"Project": "ContosoAir",
"ReflectedWorkItemIDFieldName": "Custom.ReflectedWorkItemId",
"AllowCrossProjectLinking": false,
"PersonalAccessToken": "Intentionally removed"
},
"Target": {
"Collection": "https://dev.azure.com/ITIDEVOPSTEAM/",
"Project": "ContosoAir-Migrated",
"ReflectedWorkItemIDFieldName": "Custom.ReflectedWorkItemId",
"AllowCrossProjectLinking": false,
"PersonalAccessToken": "Intentionally removed"
},
To provide sync as well as migration it is important that the tools knows which items have already been migrated. This is the purpose of the ReflectedWorkItemId field.
This field needs to be added to the Target Project Work Items. If you are using "UpdateSourceReflectedWorkItemID" then it also needs to be added to the Source.
On both system the URL pointing to the migrated item on the other system is stored here. This means there is an easy way for a user to trace work items between the source and target systems (and vice versa).
How the ReflectedWorkItemId field is added depends on whether the system.
TFS / Azure DevOps Server [XML Process] - If you are using the classic XML process you will need to use https://learn.microsoft.com/en-us/azure/devops/reference/on-premises-xml-process-model?view=azure-devops-2019
Azure DevOps Service [XML Process] - If you use the Microsoft Migration tools to take your entire collection into Azure DevOps Service then you will need to download the XML zip, change the files, and reupload. https://learn.microsoft.com/en-us/azure/devops/migrate/migration-overview?view=azure-devops
Azure DevOps Service [Inherited Process] - you can customise and add the ReflectedWorkItemId
filed using the GUI. https://learn.microsoft.com/en-us/azure/devops/organizations/settings/work/manage-process?view=azure-devops
I accidentally deleted a Task Group but I need it and I would like to restore it.
Is there any way that a deleted Task Group could be restored in Azure DevOps (VSTS)?
I see in the documentation that deleted Build Definitions can be restored but I found nothing about deleted Task Groups.
There is certainly a workaround to restore the task group, and that is creating an identical one and replacing all the references to point to the newly created task group.
For that, first you need the GUID of the deleted task group.
You can get it easily from a pipeline referencing it:
missingTaskGroup
Just go to the history tab of the given pipeline and look for the deleted task group and its GUID in the YAML after opening one of the versions using "Compare Difference".
You should find something like this, where id is the GUID of the task group:
"steps": [
{
"environment": {},
"enabled": true,
"continueOnError": true,
"alwaysRun": true,
"displayName": "Task group: testTaskGroup ",
"timeoutInMinutes": 0,
"condition": "succeededOrFailed()",
"task": {
"id": "5e417q45-afea-4f74-a126-a26ea17020dc",
"versionSpec": "1.*",
"definitionType": "metaTask"
},
"inputs": {}
}
Replacing the placeholders in the following URL and navigating to it should let you retrieve the full history of the deleted task group:
https://dev.azure.com/[yourOrganization]/[yourProject]/_taskgroup/[taskGroupGuid]
After switching to the History tab, you can just save the JSON of the version you prefer and use the Import feature in the Taskgroups page to create a new, but identical task group as the deleted one.
Please be aware that currently the suggested answer no longer works. After deleteing a taksgroup and hitting the URL the history tab yields nothing, and the export feature does not work.
Based on the documentation below, there is no restore method.
https://learn.microsoft.com/en-us/rest/api/azure/devops/distributedtask/taskgroups?view=azure-devops-rest-5.1
I want to deploy webapp and their webjobs in environments using VSTS ci/cd.
Note:
1.The webapp having three webjobs( WJ1+ (WJ2+Its instance(2))
2.The webapp having 6 webjobs( WJ1+ (WJ2+Its instance(5)).
3.its not picking the variables which we aren't adding in release pipeline.
Quick help much appreciated
Thanks,
SP
Web Jobs will not pick the variables from your release pipeline, instead it can get these variables/settings from the web app's appsettings section.
You can do that manually by setting the appsettings for the web app in Azure Portal by following this link https://learn.microsoft.com/en-us/azure/app-service/web-sites-configure
Or you can do it automatically by changing web.config/appsettings using transformation tasks in your release pipeline as instructed in this link
https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/transforms-variable-substitution?view=azure-devops
As for the web jobs deployment:
If you added the web jobs from visual studio, it will add a file under the properties folder in your web app called webjobs-list.json. If it is not there, then add it and the content should be similar to:
{
"$schema": "http://schemastore.org/schemas/json/webjobs-list.json",
"WebJobs": [
{
"filePath": "../webjob1.csproj"
},
{
"filePath": "../webjob2.csproj"
},
{
"filePath": "../webjob3.csproj"
}
]
}
I'm trying to automatically create review apps as part of my pipeline and testing procedure when pull requests are created on the corresponding GitHub repository. When the PR is created, it appears as a review app, but doesn't actually get created.
In the DevTools console, a 404 error is there about the review-app-config. I'm not sure if this is directly related, as I've successfully created a review app on a different pipeline (with a different owner) with the same error.
This 404 error changes between the file not being available at all, or that it's returning an error. When it's the latter, the file contains the following:
{"id":"missing_version","error":"Please specify a version along with Heroku's API MIME type. For example, `Accept: application/vnd.heroku+json; version=3`.\n"}
I'm creating and managing all of the apps/pipelines with the GUI on dashboard.heroku.com. The version accept header appears to be needed for the Heroku API but I've no idea how to implement it. Any help would be greatly appreciated!
Firstly check that your app.json file is valid json. If it isn't then that will cause the deployment to fall over.
Secondly check if you have any scripts in the app.json key. If you have any here and they are incorrect then this will also cause it to hand and fall over with no warning displayed.
{
"name": "App name",
"scripts": {
"deploy": "command that won't work!!"
},
...
}
You many not need any scripts in here so it can also be empty!
{
"name": "App name",
"scripts": {},
...
}
I'm deploying a resource group to Azure consisting of a VM, a network, an Automation Account with some runbooks, among other things, using a JSON Template.
I'm getting the following errors,
New-AzureRmResourceGroupDeployment : 4:49:23 PM - Resource
Microsoft.Automation/automationAccounts/runbooks
'DeployAutomationName/AzureClassicAutomationTutorial' failed with
message '{ "code": "BadRequest", "message":
"{\"Message\":\"Invalid argument specified. Argument contentLink
cannot be null.\"}"
As well as:
New-AzureRmResourceGroupDeployment : 4:49:23 PM - Resource
Microsoft.Automation/automationAccounts/modules
'DeployAutomationName/Microsoft.WSMan.Management' failed with message
'{ "code": "BadRequest", "message": "{\"Message\":\"The
ContentLink property must be supplied in PUT or re-PUT operations.\"}"
}'
These two errors repeat for all sorts of different "Assets" ( I think that's the term) of my automation account. So for modules, runbooks, certificates, and connections.
What is a contenLink, and how can I make sure it's not Null? "ContentLink" apppears nowhere in my template, nor can I found any explanation on the internet of what exactly a contentLink is, besides this. Furthermore, I'm assuming that "PUT" or "re-PUT" is part of the rest API that delivers the template, and I have no direct control over this process either. Of what use is an error message that describes problems I have no direct control over?
This problem is synonymous with many of the difficulties I've had succesfully troubleshooting Azure templates: the error messages I get seem to be describing Azure Internals that I have no understanding of nor access too. How can I troubleshoot or debug when I don't have access to the code that is actually throwing these exception, nor the explanation of what this exception means?
Thanks! Here is my template , I would have only copied the relevant text, but I haven't a clue what is relevant and what's not:
Ok, so after poking a little bit, it looks like you are missing the runbook content (the script itself). so your runbook resource should look like this:
{
"type": "Microsoft.Automation/automationAccounts/runbooks",
"name": "[parameters('runbooks_AzureAutomationTutorial_name')]",
"apiVersion": "2015-10-31",
"location": "eastus2",
"properties": {
"runbookType": "GraphPowerShell",
"logVerbose": false,
"logProgress": false,
"publishContentLink": {
"uri": "[variables('scriptUri')]",
"version": "1.0.0.0"
}
},
"resources": [],
"dependsOn": [
"[resourceId('Microsoft.Automation/automationAccounts', parameters('automationAccounts_deployautomation_name_1'))]"
]
},
and the variable:
"variables": {
"scriptUri": "https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/101-automation-runbook-getvms/Runbooks/Get-AzureVMTutorial.ps1",
},
I can't test the whole template, as I don't have base64 values, but I believe this should solve your issue. There might be another one after this, thou ;) who knows.
Reference data: https://raw.githubusercontent.com/Azure/azure-quickstart-templates/master/101-automation-runbook-getvms/azuredeploy.json
Also, you can just remove modules from the template, as they are not required, they are all the default ones, but for them the idea is the same, you are deploying the module without giving the module data.
And you might be missing other mandatory properties here and there, looks like Automation Script doesn't really work well with Azure Automation yet. You might want to resort to Powershell to provision Automation Account, as that works perfectly fine.
P.S. I have no idea what the content of the graphical runbook looks like. But i'd guess, you can export it and upload to github, and it would work.