I'm trying to publish my node application using NuGet and Azure DevOps.
Client requires to pack node_modules together with source code, so that application can be used without installing dependencies on host.
Here is part of azure-pipelines.yml responsible for pushing package:
- task: NuGetCommand#2
displayName: "Publish the artifacts"
inputs:
command: push
packagesToPush: "path-to-package.nupkg"
nuGetFeedType: internal
publishVstsFeed: "SomeFeed"
versioningScheme: byEnvVar
versionEnvVar: BuildNumber
verbosityPush: "Detailed"
arguments: "-Timeout 901"
Docs say that i can use arguments field to pass parameters to the command, but it seems it it ignored and push command always times out after 5 minutes (or 300 seconds - that is default timeout)
There is no information in the docs about format of arguments field, I just assumed it should be a string.
What am I missing?
Related
I am getting the following error when trying to run my pipeline
Job Job: Step task reference is invalid. The task name NuGetCommand is ambiguous.
Specify one of the following identifiers to resolve the ambiguity:
.NuGetCommand, .NuGetCommand
Below is my .yml file for my .Net Standard library
trigger:
- main
pool:
vmImage: 'windows-latest'
variables:
solution: '**/MyLibrary.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
steps:
- task: NuGetToolInstaller#1
- task: NuGetCommand#2
inputs:
command: 'restore'
restoreSolution: '**/MyLibrary.sln'
feedsToUse: 'config'
nugetConfigPath: './nuget.config'
- task: VSBuild#1
inputs:
solution: '**\MyLibrary.sln'
vsVersion: '15.0'
restoreNugetPackages: true
It seems to be complaining about NugetCommand#2 which doesn't make sense when it comes built in?
Edit
Have also tried using - task: 333b11bd-d341-40d9-afcf-b32d5ce6f23b#2 instead of - task: NuGetCommand#2
One may have been pushed straight into the account using tfx build tasks upload, run tfx build tasks list to find out which ones are installed and if needed delete the non-official one using tfx build tasks delete.
C:\Users\jesse>npm install tfx-cli -g
C:\Users\jesse>tfx build tasks list
TFS Cross Platform Command Line Interface v0.8.3
Copyright Microsoft Corporation
> Service URL: https://dev.azure.com/jessehouwing-dev
> Personal access token:
The one you want to keep is:
id : 333b11bd-d341-40d9-afcf-b32d5ce6f23b
name : NuGetCommand
friendly name : NuGet
visibility :
description : Restore, pack, or push NuGet packages, or run a NuGet command. Supports NuGet.org and authenticated feeds like Azure Artifacts and MyGet. Uses NuGet.exe and works with .NET Framework apps. For .NET Core and .NET Standard apps, use the .NET Core task.
version : 2.179.0
If there is one with a different guid, delete is with:
C:\Users\jesse>tfx build tasks delete --task-id the-task-id-guid-to-delete
It may also have been pushed as part of a privately shared custom extension. The marketplace will block tasks with the rame GUID, but it will allow installing a task with the same name just fine through an extension. Check your installed extensions, especially privately shared ones.
AzureDevops Task name NuGetCommand is ambiguous
According to the error message, it seems that error can happen when two tasks\extensions exist in your Azure DevOps organization with the same name.
You could use this REST API:
https://dev.azure.com/{organisationName}/_apis/distributedtask/tasks?visibility%5B%5D=Build
to check here for possible duplicates.
To resolve this issue, you could use command line to invoke nuget.exe to restore the solution:
nuget.exe restore a.sln -source "xx" -PackagesDirectory
In our .NET Web API project, we tried to build API project in Azure DevOps and publish the artifact to a folder with the pipeline task below:
- task: DotNetCoreCLI#2
displayName: Publish web API artifact
inputs:
command: publish
publishWebProjects: false
arguments: '$(Build.SourcesDirectory)\XYZ.Research.API\XYZ.Research.API.csproj --configuration $(BuildConfiguration) --output testpath'
zipAfterPublish: true
modifyOutputPath: true
But I am not sure which folder the artifact is kept. Below is the log from this step:
2020-07-31T12:04:23.6282186Z ##[section]Starting: Publish web API artifact
2020-07-31T12:04:23.6590490Z ==============================================================================
2020-07-31T12:04:23.6591051Z Task : .NET Core
2020-07-31T12:04:23.6591393Z Description : Build, test, package, or publish a dotnet application, or run a custom dotnet command
2020-07-31T12:04:23.6591740Z Version : 2.172.2
2020-07-31T12:04:23.6591974Z Author : Microsoft Corporation
2020-07-31T12:04:23.6592357Z Help : https://learn.microsoft.com/azure/devops/pipelines/tasks/build/dotnet-core-cli
2020-07-31T12:04:23.6592942Z ==============================================================================
2020-07-31T12:04:25.5581194Z [command]C:\windows\system32\chcp.com 65001
2020-07-31T12:04:25.5581889Z Active code page: 65001
2020-07-31T12:04:25.5583746Z Info: .NET Core SDK/runtime 2.2 and 3.0 are now End of Life(EOL) and have been removed from all hosted agents. If you're using these SDK/runtimes on hosted agents, kindly upgrade to newer versions which are not EOL, or else use UseDotNet task to install the required version.
2020-07-31T12:04:25.5588792Z [command]C:\hostedtoolcache\windows\dotnet\dotnet.exe publish d:\a\1\s\XYZ.Research.API\XYZ.Research.API.csproj --configuration Release --output testpath
.....
some warning message ignored
.....
2020-07-31T12:04:38.0843543Z XYZ.Research.API -> d:\a\1\s\XYZ.Research.API\bin\Release\netcoreapp3.0\XYZ.Research.API.dll
2020-07-31T12:04:38.9127845Z XYZ.Research.API -> d:\a\1\s\testpath\
2020-07-31T12:04:46.0295716Z Info: Azure Pipelines hosted agents have been updated to contain .Net Core 3.x (3.1) SDK/Runtime along with 2.1. Unless you have locked down a SDK version for your project(s), 3.x SDK might be picked up which might have breaking behavior as compared to previous versions.
2020-07-31T12:04:46.0296632Z Some commonly encountered changes are:
2020-07-31T12:04:46.0297619Z If you're using `Publish` command with -o or --Output argument, you will see that the output folder is now being created at root directory rather than Project File's directory. To learn about more such changes and troubleshoot, refer here: https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/build/dotnet-core-cli?view=azure-devops#troubleshooting
2020-07-31T12:04:46.0442329Z ##[section]Finishing: Publish web API artifact
Because we will need the file location in next step (deployment), I tried
d:\a\1\s\testpath\XYZ.Reserch.API.zip
d:\a\1\s\testpath\XYZ.Reserch.API\XYZ.Reserch.API.zip
but none of these location has the artifact file.
Did anyone see this issue before? Any help would be appreciated.
------------------- update -------------------------------
As #Source Code suggested, I used task "PowerShell#2" and find that the artifact file are actually in "D:\a\1\s\testpath\testpath.zip". That means the 'testpath' sub-folder are created in $(Build.SourceDirectory) and the artifact file are also renamed to 'test.zip'.
I would recommend that you add a PowerShell/Bash/Cmd task after your DotNetCoreCLI#2 task and run a inline script with the 'ls' command that should list all the items to the results for you. This will allow you to see what is actually there after the task.
If on a Windows agent:
- task: PowerShell#2
displayName: List Files Post Publish
inputs:
targetType: inline
script: Get-ChildItem
If on Linux or Mac
- task: Bash#3
displayName: List Files Post Publish
inputs:
targetType: inline
script: ls
Additionally I noticed you're providing your csproj file via the arguments parameter. There is a parameter named projects which should be used for this. Also you may consider using the the artifacts staging directory as your output directory. The task would look like this:
- task: DotNetCoreCLI#2
displayName: Publish web API artifact
inputs:
command: publish
projects: '$(Build.SourcesDirectory)\XYZ.Research.API\XYZ.Research.API.csproj'
publishWebProjects: false
arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)'
zipAfterPublish: true
modifyOutputPath: true
One important thing to note is if you do change the output directory ensure that you change the working directory for the PowerShell or Bash tasks so you output the contents of the correct directory. It defaults to the $(Build.SourcesDirectory) so ensure that you change this if needed.
In Azure DevOps, I'd like to use the dotnet core CLI task to push a package with the --skip-duplicate option set. How do I do that?
I tried to set arguments: --skip-duplicate, but that's not getting reflected in the executed command.
I tried custom command with custom: nuget push, but that indicates nuget push isn't a valid custom command.
How do I make the DotNetCorCLI#2 task perform dotnet nuget push <pathspec> --skip-duplicate (with also the --source option set to an internal package source)
Try to use custom: nuget and put the push in argument. Check the following syntax:
steps:
- task: DotNetCoreCLI#2
displayName: 'dotnet nuget push'
inputs:
command: custom
custom: nuget
arguments: 'push *.nupkg -s https://pkgs.dev.azure.com/xxxx/_packaging/xxx/nuget/v3/index.json --skip-duplicate'
You should be able to use the nuget authenticate and the nuget push instead of the dotnet core CLI. It has a couple of more features
- task: NuGetAuthenticate#0
displayName: 'NuGet Authenticate'
- task: NuGetCommand#2
displayName: 'NuGet push'
inputs:
packagesToPush: '$(Build.ArtifactStagingDirectory)/**/*.nupkg'
command: push
feedsToUse: 'select'
publishVstsFeed: 'feedname'
allowPackageConflicts: true
I had the same issue. I managed to fix it this way:
- task: NuGetAuthenticate#0
- script: dotnet nuget push --api-key az --skip-duplicate --source https://pkgs.dev.azure.com/{organization}/{project?}/_packaging/{feed1}/nuget/v3/index.json *.nupkg
workingDirectory: $(Build.ArtifactStagingDirectory)
Of course, replace {organization} with your org name in azure.
{project?} is useless if your feed is organization scoped and
{feed1} is your nuget feed name.
The NuGetAuthenticate task will authenticate by default all feeds within azure.
To get authentication works outside azure feeds, take a look to the official docs
Update
If nuget push randomly fails with 401, an accepted workaround is to add these variables to your yaml, as suggested here
variables:
NUGET_PLUGIN_REQUEST_TIMEOUT_IN_SECONDS: '30'
NUGET_PLUGIN_HANDSHAKE_TIMEOUT_IN_SECONDS: '30'
I have set up a build pipeline for a model library that's shared between several of my projects. I'm accessing it through a private feed in Azure DevOps, and it works just fine. I can retrieve the library in Visual Studio and my projects all get the most up-to-date version. However, in the feed are all the dependency libraries used within the model library (e.g. Microsoft.Azure.Storage.Blob, System.Threading, Microsoft.AspNetCore, etc.). I haven't been able to find any guidance on why this is happening, if it's the expected behavior, or if I'm screwing something up. My YAML file for the build pipeline is below:
Also, does anyone know a better to handle package versioning? This seems really hacky, but it was the only way I could get auto-incrementing versions to work.
# Starter pipeline
# Start with a minimal pipeline that you can customize to build and deploy your code.
# Add steps that build, run tests, deploy, and more:
# https://aka.ms/yaml
name: $(projectName)-$(majorMinorVersion).$(semanticVersion)
pool:
vmImage: 'windows-latest'
# pipeline variables
variables:
majorMinorVersion: 1.1
# semanticVersion counter is automatically incremented by one in each execution of pipeline
# second parameter is seed value to reset to every time the referenced majorMinorVersion is changed
semanticVersion: $[counter(variables['majorMinorVersion'], 0)]
projectName: 'MyProject.Models'
buildConfiguration: 'Release'
projectPath: 'Shared/MyProject.Models.csproj'
fullVersion: '$(majorMinorVersion).$(semanticVersion)'
steps:
# show version number on start
- task: Bash#3
inputs:
targetType: 'inline'
script: |
echo Building $(projectName)-$(fullVersion)
- task: DotNetCoreCLI#2
inputs:
command: 'pack'
packagesToPack: $(projectPath)
versioningScheme: 'byEnvVar'
versionEnvVar: 'fullVersion'
- task: DotNetCoreCLI#2
inputs:
command: 'push'
packagesToPush: '$(Build.ArtifactStagingDirectory)/MyProject.Models*.nupkg'
nuGetFeedType: 'internal'
publishVstsFeed: '<feed GUID>'
Dependencies getting copied to private feed in Azure DevOps
That because your private Nuget Feed set nuget.org as an Upstream source by default if you set Package from public sources enable when you create the this feed:
Then go to Setting->Upstream source, you will find there are three public sources listed:
When we download any packages from the Upstream sources, it will been cached in the Artifacts, you will see it next time. They are cached packages from upstream sources, so we do not need to download them again from upstream sources next time we use them, and the included upstream sources are all approved by MS, so you do not need to worry about them.
Besides, if you still worry about them, you can disable the Upstream sources, but in this case, you need publish all the dependencies to your private feed, otherwise, your model library package will throw the error could not found the dependencies.
Hope this helps.
I've an ASP.NET Core application I'm publishing on a dedicated server via Azure DevOps build/release pipelines.
I'm managing the application version number with the GitVersion task (gittools.gitversion.gitversion-task.GitVersion#4) in the YAML build.
The build step is something like:
- task: DotNetCoreCLI#2
displayName: 'dotnet build'
inputs:
command: custom
custom: build
workingDirectory: src/MyAppProjectFolder
arguments: '-p:Version=$(GitVersion.FullSemVer)'
And is correctly generating the .exe with the given FullSemVer (I'm inspecting the Azure agent work folder)
Then I've the publish step:
- task: DotNetCoreCLI#2
displayName: 'dotnet publish'
inputs:
command: publish
publishWebProjects: false
arguments: '--output $(build.artifactstagingdirectory) --no-restore --no-build'
workingDirectory: src/MyAppProjectFolder
For some reason the same .exe i found in the C:\agent_work\1\a\a.zip created by the publish DOESN'T have the correct version number, but the generic 1.0.0.
If I "emulate" the pipelines manually on the same server (with dotnet build and dotnet publish manually via powershell, same parameters) everything works as expected.
What's going on? Is there a way to ensure the application to keep the $(GitVersion.FullSemVer) version?
Note: I had to add
- task: UseDotNet#2
displayName: 'Use .Net Core sdk 2.1.x'
inputs:
packageType: sdk
version: 2.1.x
installationPath: $(Agent.ToolsDirectory)/dotnet
includePreviewVersions: true
in front of each NET Core task, as explained here, after the agents have been updated to .NET Core 3.0 (before these builds worked well).
Try adding -p:Version=$(GitVersion.FullSemVer) to your arguments for the publish step.