Sonarqube error in VSTS Build when version 4 of sonar extension is used.
Error -
[SQ] API GET. '/api/server/version' failed, error was:
{"code":"UNABLE_TO_GET_ISSUER_CERT_LOCALLY"} .
SonarQube extension version 3 build runs successfully.
We are using Sonarqube version 7.1
I also faced same error:
[error][SQ] API GET '/api/server/version' failed, error was: {"code":"UNABLE_TO_GET_ISSUER_CERT_LOCALLY"
To fix this issue:
First I installed Java 17 to devOps build agent machine https://www.oracle.com/java/technologies/javase/jdk17-archive-downloads.html
Java SE Development Kit 17.0.5 Windows x64 Installer.
Installed path: C:\Program Files\Java\jdk-17.0.5
Then add two devOps build pipeline variables:
NODE_EXTRA_CA_CERTS and SONAR_SCANNER_OPTS
SONAR_SCANNER_OPTS:
Copy your cacerts and replace existing one.
path: “…\Java\jdk 17.0.5\lib\security\cacerts”
Then add both paths in devOps SONAR_SCANNER_OPTS variable:
-Djavax.net.ssl.trustStore="C:\program files\Java\jdk 17.0.5\lib\security\cacerts"
-Djavax.net.ssl.keyStore="C:\program files\Java\jdk 17.0.5\lib\security\cacerts"
NODE_EXTRA_CA_CERTS:
copy your cert *.PEM file and replace it the existing one in devops build agent path: C:\devOps_Agent\sonarchain.pem
After this step SonarQube prepare starting to work.
Related
I'm currently developing a Blazor WebAssembly application that will be deployed on an Azure Static Web App through a BitBucket pipeline.
pipelines:
branches:
main:
- step:
name: Deploy to test
deployment: test
script:
- pipe: microsoft/azure-static-web-apps-deploy:main
variables:
APP_LOCATION: "$BITBUCKET_CLONE_DIR/PriorityCasesClient/PriorityCasesClient"
OUTPUT_LOCATION: "$BITBUCKET_CLONE_DIR/PriorityCasesClient/PriorityCasesClient/wwwroot"
API_TOKEN: $deployment_token
I however keep running into below error when Oryx is trying to build the solution.
It seems that the pipeline points to the correct locations and the solution is found and correctly restored, as can be seen below, but when Roslyn kicks in it hits me with the following:
error MSB6004: The specified task executable location "/ (deleted)" is invalid
Successfully installed workload(s) wasm-tools.
Determining projects to restore...
Restored /opt/atlassian/pipelines/agent/build/PriorityCasesClient/PriorityCasesClient/PriorityCasesClient.csproj (in 1.84 sec).
Publishing to directory /bin/staticsites/ss-oryx/app...
Microsoft (R) Build Engine version 17.2.0+41abc5629 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.
Determining projects to restore...
All projects are up-to-date for restore.
/opt/dotnet/6.0.301/sdk/6.0.301/Roslyn/Microsoft.CSharp.Core.targets(75,5): error MSB6004: The specified task executable location "/ (deleted)" is invalid. [/opt/atlassian/pipelines/agent/build/PriorityCasesClient/PriorityCasesClient/PriorityCasesClient.csproj]
---End of Oryx build logs---
Oryx has failed to build the solution.
Can anyone possible see something wrong with my pipeline, or point me in a direction?
I'm using an 'Install MSI' task to install an msi file as part of a deployment. The task is throwing the error:
2022-02-22T06:42:35.0716371Z ActionData: Updating component registration
2022-02-22T06:42:35.0839323Z ##[error]Unable to process command '##vso[task.logdetail id=5c578bc6-8e75-4147-992e-fe8cd643eaa2;parentid=00000000-0000-0000-0000-000000000000;name=;type=release;order=1]Updating component registration' successfully. Please reference documentation (http://go.microsoft.com/fwlink/?LinkId=817296)
2022-02-22T06:42:35.0888633Z ##[error]Name is required for this new timeline record.
I'm using Azure DevOps on a local Team Foundation Server for the build and deploy process. From the error message I can see that the 'Name' parameter is missing. The deployment works fine when I'm installing to physical machines, but gives the above error when I'm installing to virtual machines.
There were apparently lots of people who had variants of this issue back in 2016, like this guy on social.msdn or this guy on github or this guy on SO. Apparently in 2016 it was possible to turn off "Record project details", however this option is not available in newer versions of Azure Devops.
Does anyone know how to fix this issue in newer versions of Azure DevOps?
Versions: Azure DevOps Server 2020 Update 1.1, Agent 2.153.1, Install MSI 0.1.20.
More a workaround than an answer, but I ended up switching the 'Install MSI' task to a regular 'Command line ' task.
Using the command line with the 'msiexec' command lets you install msi files just as easily as using the 'Install MSI' task.
I am trying to restore NuGet packages from the Azure Artifacts feed with the task "Nuget restore" which is giving an error -
2020-03-17T06:16:01.923910Z Resolved from tool cache: 4.1.0
2020-03-17T06:16:01.939365Z Using version: 4.1.0
2020-03-17T06:16:01.924520Z Found tool in cache: NuGet 4.1.0 x64
2020-03-17T06:16:02.080668Z [command]C:\Windows\system32\chcp.com 65001
2020-03-17T06:16:02.007116Z Active code page: 65001
2020-03-17T06:16:02.012223Z Detected NuGet version 4.1.0.2450 / 4.1.0
2020-03-17T06:16:02.081611Z SYSTEMVSSCONNECTION exists true
2020-03-17T06:16:04.157611Z ##[error]Error: Error: read ECONNRESET
2020-03-17T06:16:04.190260Z ##[error]Packages failed to restore
Details -
Server - Azure DevOps server 2019
Azure DevOps build pipeline
Azure Artifacts Feed - offline
Agent Version 2.144.2
What I noticed
my "Nuget Restore" task is working well when my build machine is in the same LAN with azure DevOps server and giving an error with the different LAN's build machine.
I googled but did not find anything. some pages showing this error is because of the proxy, some page is showing version issue of NuGet.
Not getting what exactly the issue is. Can someone help with this?
Build pipeline fails at task 'push packages to Octopus'
##[section]Starting: Push Packages to Octopus
Task : Push Package(s) to Octopus
Description : Push your NuGet or Zip package to your Octopus Deploy Server
Version : 4.0.387
Author : Octopus Deploy
Help : Version: 4.0.387. More Information
65978706-f70e-4ac0-8dc7-7f61db0ce4d8 exists true
Attempting to contact https://g.octopushq.com to find Octo command line tool version latest
Checking local tool cache
Found tool in cache: Octo 6.13.1 x64
Looking for E:\vsts\a_tool\Octo\6.13.1\x64*Octo.dll
Prepending PATH environment variable with directory: E:\vsts\a_tool\Octo\6.13.1\x64
[command]C:\Windows\system32\cmd.exe /D /S /C "E:\vsts\a_tool\Octo\6.13.1\x64\Octo.cmd version"
E:\vsts\a\5833\s>dotnet "E:\vsts\a_tool\Octo\6.13.1\x64/Octo.dll" version
6.13.1
[command]C:\Windows\system32\cmd.exe /D /S /C "E:\vsts\a_tool\Octo\6.13.1\x64\Octo.cmd push "--server=https://octopus.bentley.com/" "--apiKey=***" "--space=Spaces-1" "--package=E:/vsts/a/5833/a/PGDQApp.2019.9.16.2.nupkg" "--overwrite-mode=OverwriteExisting""
E:\vsts\a\5833\s>dotnet "E:\vsts\a_tool\Octo\6.13.1\x64/Octo.dll" push "--server=https://octopus.bentley.com/" "--apiKey=***" "--space=Spaces-1" "--package=E:/vsts/a/5833/a/PGDQApp.2019.9.16.2.nupkg" "--overwrite-mode=OverwriteExisting"
Octopus Deploy Command Line Tool, version 6.13.1
Detected automation environment: "AzureDevOps"
Found space: Default (Spaces-1)
Space name specified, process is now running in the context of space: Default
Handshaking with Octopus Server: https://octopus.bentley.com/
Handshake successful. Octopus version: 2019.7.13; API version: 3.0.0
Authenticated as: Neha Lahoti
Pushing package: E:\vsts\a\5833\a\PGDQApp.2019.9.16.2.nupkg...
Requesting signature for delta compression from the server for upload of a package with id 'PGDQApp' and version '2019.9.16.2'
No package with the same ID exists on the server
Falling back to pushing the complete package to the server
You do not have permission to perform this action. Please contact your Octopus administrator. Missing permission: BuiltInFeedPush
Exit code: -5
[error]Error: The process 'E:\vsts\a_tool\Octo\6.13.1\x64\Octo.cmd' failed with exit code 4294967291
[error]Failed to push package. The process 'E:\vsts\a_tool\Octo\6.13.1\x64\Octo.cmd' failed with exit code 4294967291
[section]Finishing: Push Packages to Octopus
You do not have permission to perform this action. Please contact your Octopus administrator. Missing permission: BuiltInFeedPush Exit code: -5
Seems like you are missing permissions to push a package?
Keep in mind that in Octopus you need to have permissions to all the projects that are using that package in order to push a new version of it (as pushing a package might trigger a new deployment on specific projects)
I am getting the following error while running a workflow in microsoft release management 2013 update 4:
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.AggregateException: One or more errors occurred. ---> Microsoft.TeamFoundation.Release.Common.Helpers.OperationFailedException: System.AggregateException: Failed to install 'VisualStudioRemoteDeployerbd3a8a59-325a-45d0-89f5-86a548554a12' from service executable path VisualStudioRemoteDeployer.exe . Consult the logs below:
c:\Users\vmadmin\AppData\Local\Temp\mfurnl9w.0.cs(95) : ; expected
c:\Users\vmadmin\AppData\Local\Temp\mfurnl9w.0.cs(94) : IntPtr policyHandle = IntPtr.Zero;
c:\Users\vmadmin\AppData\Local\Temp\mfurnl9w.0.cs(95) : >>> var attributes = new LSA_OBJECT_ATTRIBUTES()
c:\Users\vmadmin\AppData\Local\Temp\mfurnl9w.0.cs(96) :
I am using a vNext Release Template. I have added an action "Deploy using PS/DSC" which is supposed to execute a powershell script on the machine.
All I get is the above error.
I have verified that remoting is setup as per here (on-premise section): https://www.visualstudio.com/en-us/get-started/deploy-no-agents-vs.aspx
I have also referenced this: http://roadtoalm.com/2015/02/04/start-with-visual-studio-release-management-vnextvs-rm-for-dummies/
but our error is slightly different as it doesn't complain about the account. Although i am assuming the account is ok... I did use a couple variations and when the account is incorrect i get an obvious failure.
any help would be appreciated.
I found this question because I had the same issue. In RoadToAlm article he is using Windows Server 2012 on his VM. My Azure VM was Windows Server 2008 SP2 and I resolved the issue by installing Windows Management Framework 3.0 (http://go.microsoft.com/?linkid=9811175) which includes a newer Powershell than was installed on my server. After this update the issue was resolved.
I was facing the same issue on a destination Windows Server 2008 R2. I just shift down the UAC level and it let the deployment tools be copied by the task into the c:\Windows\DtlDownloads folder (with VisualStudioRemoteDeployer.exe).
From the moment this file was available, the artifact copy had been successful.