This doesn't happen very often, but I'd like to know why Azure pipeline sometimes fail.. Here is the error:
Here is the raw logs from Azure:
The task also requires permissions to upload your Lambda function or
serverless application content to the specified Amazon S3 bucket.
Depending on the size of the application bundle, either putObject or
the S3 multi-part upload APIs may be used.
============================================================================== Configuring credentials for task ...configuring AWS credentials from
service endpoint '0fccf46b-rAnDom-GuId-f8a4f1351ac1' ...endpoint
defines standard access/secret key credentials Processing Lambda
project at D:\a\1\s\FooService\FooProject.Services.Foo Reading
existing aws-lambda-tools-defaults.json Clearing out profile foo so
task credentials will be used. Configuring region for task
...configured to use region ap-southeast-1, defined in task.
[command]"C:\Program Files\dotnet\dotnet.exe" tool install -g
Amazon.Lambda.Tools Since you just installed the .NET Core SDK, you
will need to reopen the Command Prompt window before running the tool
you installed. You can invoke the tool using the following command:
dotnet-lambda Tool 'amazon.lambda.tools' (version '4.0.0') was
successfully installed.
[command]"C:\Program Files\dotnet\dotnet.exe" restore Restore
completed in 63.09 ms for
D:\a\1\s\Infrastructure\FooProject.Infrastructure\FooProject.Infrastructure.csproj.
Restore completed in 63.07 ms for
D:\a\1\s\FooService\FooProject.Services.Foo\FooProject.Services.Foo.csproj.
Beginning Serverless Deployment Performing package-only build of
serverless application, output template will be placed in
D:\a\1\a\serverless.template [command]"C:\Program
Files\dotnet\dotnet.exe" lambda package-ci -ot
D:\a\1\a\serverless.template --region ap-southeast-1 --s3-bucket
foo-dev-bucket --disable-interactive true Could not execute
because the specified command or file was not found. Possible reasons
for this include: * You misspelled a built-in dotnet command. *
You intended to execute a .NET Core program, but dotnet-lambda does
not exist. * You intended to run a global tool, but a
dotnet-prefixed executable with this name could not be found on the
PATH.
[error]Error: The process 'C:\Program Files\dotnet\dotnet.exe' failed with exit code 1
[section]Finishing: Deploy .NET Core to Lambda: fooProject-api-foo
Here is the setup:
Related
I've a strange problem. I try to restore a .net core application with dotnet restore command in Azure pipeline. One of my package is on my local feed (repo and feed are in same azure devops project).
With classic editor (UI editor) I've no problem but with yaml file restore is unable. I've the error : error NU1301: Unable to load the service index for source
I export yaml from classic editor and copy it in a new yaml pipeline file but build faild also... The configuration of restore task is the same but it doesn't work with yaml.
What is stranger is that the restore task worked friday (with yaml) but fail since yesterday without changes...
I'don't undersand anything... Who would have an idea ?
Thanks
(The agent is an azure agent)
The content of yaml file :
jobs:
- job: Job_1
displayName: Agent job 1
pool:
vmImage: windows-2019
steps:
- checkout: self
fetchDepth: 1
- task: DotNetCoreCLI#2
displayName: "dotnet restore"
inputs:
command: restore
projects: '**\*.sln'
vstsFeed: "afcdef6a-5c72-4a0e-90c5-33d9e751869c/ab1da1d1-3562-4a0a-9781-4f4d80de93ba"
For Classic pipeline, your Build job authorization scope may be Project Scope(Current project)
Classic Pipeline Options
When you use yaml pipeline, the Build job authorization scope is defined by
Project setting->Limit job authorization scope to current project for non-release pipelines
Project Settings
If it is off, the build job authorization scope is Organization Scope (Project Collection)
If it is on, the build job authorization scope is Project Scope (Current project)
You could try to add Project Collection Build Service (OrgName) to Feed setting->Permissions.
Feed settings
Apologies from the start but please bear with me, I am still rather novice at this so if you see any issues glaringly obvious, please forgive me.
I am working at a company where some devs are trying to have us deploy some .NET Core applications to containers in Azure Kubernetes Service (AKS). From my understanding, they have been written in .NET Core 3.1. The goal is to run this process using a CI/CD Azure Pipeline, using Azure Repos as repository, using a build pipeline to create the docker image, push image to our Azure Container Registry and create an artifact for the release pipeline to then deploy (using helm) contianers into the AKS.
File Structure is as follows:
Dockerfile
FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
EXPOSE 80
FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
COPY ["AppFolder1\App.csproj", "."]
RUN dotnet restore "AppFolder1\App.csproj"
COPY . .
RUN dotnet build "AppFolder1\App.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "AppFolder1\App.csproj" -c Release -o /app/publish
FROM base AS final
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "DotNet.Docker.dll"]
ERROR
Question: Could there be an issue with 6.0 sdk when trying to deploy app made with .net core 3.1?
running "kubectl get pods -n redacted-namespace"
a) retrieves two pods with CrashLoopBackOff Status showing 9 restarts
running "kubectl define pod -n redacted-namespace" retrieves information on pods
a) both pods show successful pod scheduling - Successfully assigned redacted-namespace/ to aks-nodepool1-02 AND aks-nodepool1-00
b) Both show multiple successful pull of image
c) Both show creation of container and start of container
d) End message:
Warning BackOff 58s (x117 over 26m) kubelet Back-off restarting failed container
--ATTEMPTS TO SOLVE--
It was suggested that the Dockerfile was to blame. Spent time creating and running pipeline with multiple iterations of dockerfile, including changing .net versioning to 3.1 from 6.0. No successful pipelines using these dockerfiles yet.
running kubectl logs <pod-name> -n redacted-namespace:
Could not execute because the application was not found or a compatible .NET SDK is not installed.
Possible reasons for this include:
* You intended to execute a .NET program:
The application 'DotNet.Docker.dll' does not exist.
* You intended to execute a .NET SDK command:
It was not possible to find any installed .NET SDKs.
Install a .NET SDK from:
https://aka.ms/dotnet-download
I had figured that the installation of the .NET SDK should have been handled by the dockerfile line 1, however it doesn't seem to be working properly. In the meantime, adding in pipeline release Agent Task Use .NET Core sdk 6.0 and deleting previous pods to try again.
Re-running pipeline release - No effect. Likely .NET Core SDK install agent task does not work inside of each pod and is therefore not available as an installed resource within pods and replicas.
Apparently there were TWO problems with the Dockerfile. The first and foremost, #Hans Kilian, you're absolutely right. Apparently they were using .NET 3.1. The other issue was the ENDPOINT I had set up was not pointing to the right .dll file. This I found by going to Solutions/App.sln and pulled the name from the Project line (something like Project("################################")= "Project_name"... Its working and running just fine now. Thank you!
I'm trying to build a Release pipeline that is triggered by a new version of a published dotnet core tool. The trigger works fine, but I'm unable to install and run the tool in my Tasks.
CURRENTLY:
Running a Command Line Task results in a 401:
dotnet tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp
C:\Program Files\dotnet\sdk\3.0.100\NuGet.targets(123,5): error : Unable to load the service index for source https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json. [C:\Users\VssAdministrator\AppData\Local\Temp\h0g1c35v.eny\restore.csproj]
C:\Program Files\dotnet\sdk\3.0.100\NuGet.targets(123,5): error : Response status code does not indicate success: 401 (Unauthorized). [C:\Users\VssAdministrator\AppData\Local\Temp\h0g1c35v.eny\restore.csproj]
The tool package could not be restored.
Tool 'myapp' failed to install. This failure may have been caused by:
* You are attempting to install a preview release and did not use the --version option to specify the version.
* A package by this name was found, but it was not a .NET Core tool.
* The required NuGet feed cannot be accessed, perhaps because of an Internet connection problem.
* You mistyped the name of the tool.
For more reasons, including package naming enforcement, visit https://aka.ms/failure-installing-tool
This leads me to believe that I'm missing something here, making it more complicated than it needs to be, or thinking about this the wrong way. The tools in the feed can be installed locally, so I believe it's my release approach.
I'm currently looking into Personal Access Tokens (PAT)
PREVIOUSLY:
If I use the .Net Core task and the custom option:
The logs show a malformed command passed to dotnet.exe:
[command]"C:\Program Files\dotnet\dotnet.exe" "dotnet tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp"
or
[command]"C:\Program Files\dotnet\dotnet.exe" "tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp"
I've tried varying arguments and I tend to always see the same error message:
Could not execute because the specified command or file was not found.
Possible reasons for this include:
* You misspelled a built-in dotnet command.
* You intended to execute a .NET Core program, but dotnet-dotnet tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp does not exist.
* You intended to run a global tool, but a dotnet-prefixed executable with this name could not be found on the PATH.
Your custom dotnet command is quoted and dotnet is repeated : dotnet.exe" "dotnet tool install ..." so the command is misinterpreted.
You can use the Command Line task and set the dotnet command directly :
dotnet tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp
Using the .Net Core task works perfect for us.
Since the dotnet command is quoted, you need to set tool as the command and update into arguments. NuGet credentials can be provided with NuGet Auth task if needed.
Here is my walkaround:
I firstly published my private dotnet tool nupkg file also as an universal package to the same Azure Artifacts feed.
I was able to then use Universal Package task to download the .nupkg file into $(System.DefaultWorkingDirectory)/nupkgs/. This task will handle the authorization to Azure Artifacts feeds.
steps:
- task: UniversalPackages#0
displayName: 'Download mytool.cli.universal'
inputs:
downloadDirectory: '$(System.DefaultWorkingDirectory)/nupkgs/'
vstsFeed: '63d4aa2f-3ae7-4c27-8c18-aa8e3a9ff353'
vstsFeedPackage: '916d9a27-2c07-4071-8631-377f2ac08ed7'
vstsPackageVersion: 0.2.0
I then had the DotNetCoreCLI task to install my nupkg locally in agents.
steps:
- task: DotNetCoreCLI#2
displayName: 'Install mytool as a dotnet tool'
inputs:
command: custom
custom: tool
arguments: 'install --global mytool.CLI --add-source ./nupkgs --version 0.2.0'
You need to add the nuget authenticate task before you try to access the nuget feed
I'm getting a non fatal exception while running the dotnet sonarscanner utility to send data to our sonarqube instance.
During "dotnet sonarscanner end" command an exception is being thrown of "Failure during analysis, Node.js command to start eslint-bridge was: /usr/bin/node /builds/app-namespace/app-name/.sonarqube/out/.sonar/.sonartmp/eslint-bridge-bundle/node_modules/eslint-bridge/bin/server 44002
java.lang.IllegalStateException: Failed to start server (10s timeout)"
Im currently running the command in an alpine docker container with
node : v10.14.2
dotnetcore: 2.2.3
The node and npm commands are available from the path and I have also specified the sonar.nodejs.executable in the sonarqube xml config.
Additionally what is the node package used for relating to a dotnet project?
The content is still being deployed to our sonarqube instance but I would like to understand the cause of the exception.
For C#/VB.NET code, the code analysis takes place in the build step because the SonarC#/VB.NET rules are written as Roslyn rules.
However, for most other languages analysed by SonarQube/Cloud, the analysis takes place in the scanner end step. The scanner downloads the language plugins from the SonarQube/Cloud server and calls each one to give it the chance to analyse any files it can handle.
The SonarJS plugin works with ESLint which uses NodeJS i.e. the node package is being used to analyse JavaScript files.
I want to create custom build task, that would do invoke dotnet core CLI tool. I've used VSTS DevOps Task SDK/node to get or install the tool:
import tl = require('vsts-task-lib/task');
async function getLibmanTool() {
let libmanExePath = tl.which('libman');
if (!libmanExePath){
console.log("Libman CLI not found. Installing..")
var dotnet = tl.tool(tl.which('dotnet', true));
await dotnet.arg(['tool', 'install', '-g', 'Microsoft.Web.LibraryManager.Cli']).exec();
}
libmanExePath = tl.which('libman', true); //this line throws, see output
return tl.tool(libmanExePath);
}
However, when I use the tool in Build Pipeline:
I'm getting following error:
Libman CLI not found. Installing..
[command]C:\hostedtoolcache\windows\dncs\2.1.105\x64\dotnet.exe tool install -g Microsoft.Web.LibraryManager.Cli
Since you just installed the .NET Core SDK, you will need to reopen the Command Prompt window before running the tool you installed.
You can invoke the tool using the following command: libman
Tool 'microsoft.web.librarymanager.cli' (version '1.0.163') was successfully installed.
##[error]Unable to locate executable file: 'libman'. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also verify the file has a valid extension for an executable file.
It look like when I install .NET Core SDK in the pipleline, it is unable to find the dotnet tool
Question:
How do I install and then safely use the dotnet core tool? Is the any way to workaround following?
Since you just installed the .NET Core SDK, you will need to reopen the Command Prompt window before running the tool you installed
There isn't any workaround to avoid reopening the CMD as far as I know.
To get it work, you could specify the install path when installing the package and then call the full path to the liman.exe. Or if you want to install it globally with "-g", then the path to the liman.exe should be "%USERPROFILE%\.dotnet\tools\liman.exe".