Build pipeline failed for below DownloadPipelineArtifact#2 task in my VB.Net App Deployment.
##[error]No builds currently exist in the pipeline definition supplied.
Code for DownloadPipelineArtifact#2 task in azure-pipelines.yml file is displayed as seen below:
Requesting assistance on the same.
That task fails because you havent published an artifact with that pipeline.
you have 2 different ways to publish artifacts:
publish build artifacts (deprecated) used mostly in classic pipelines
can only be downloaded with download build artifact step
publish pipeline artifacts are used to publish an artifiact available for this same build or another pipeline
can only be downloaded from a download pipeline activity
You need to publish your build using publish pipeline artifact first (check if not already).
So first check the source pipelien with definition 370 from Project StarsDemo, and see if the latest build published an artifact or had an issue.
Also, per documentation, the runId is required (aka pipelineId, buildId).
I was able to resolve the issue by changing runVersion value to latest instead of latestFromBranch , after which the pipeline build successfully.
Related
I am beginner to A and just starting to work in it
What task I must add in project ASP.NET CORE to Azure DevOps Pipelines to pass the build number from the azure devops pipeline to the project code
Client.Shell.csproj:
<MinimumRequiredVersion> 4.60.0825.700 </MinimumRequiredVersion>
<ApplicationRevision> 716 </ApplicationRevision>
<ApplicationVersion> 4.60.0825.% 2a </ApplicationVersion>
https://i.stack.imgur.com/BXyHm.png
You can do something like this, Replace "1.2.3" with your build parameter.
dotnet publish ./MyProject.csproj /p:Version="1.2.3" /p:InformationalVersion="1.2.3-qa"
Look at this https://github.com/dotnet/docs/issues/7568
When a pipeline runs, it usually performs get sources action first. So you just need to map the correct project path, then the pipeline will get entire project to the Agent's working folder.
To update the version in .csproj file, and to pass the build number from the azure devops pipeline, you can check Assembly Info extension, and use the variable $(Build.BuildNumber) in the version field.
This extension can update project AssemblyInfo files and .Net Core / .Net Standard project files .csproj. For detailed instructions on how to configure the extension please see the following link:
https://github.com/BMuuN/vsts-assemblyinfo-task/wiki/Versioning
If you want to update the file in repo, you still need to run git push command to push the changes to the repo.
I'm trying to restore a NuGet package from an Azure Devops Artifact to my local installation as part of a gulpfile script.
However, I'm getting a
Response status code does not indicate success: 401 (Unauthorized).
with:
Unable to load the service index for source https://my-visualstudio-dot-com-npm-feed-here
I've tried creating a nugetauth.npmrc file with the following content:
registry=https://my-visualstudio-dot-com-npm-feed-here
always-auth=true
I then run:
vsts-npm-auth -config nugetauth.npmrc
to generate my new .npmrc file, which I then place in the same directory as my package.json and gulpfile.js files.
When I subsequently run my 'Nuget-restore' task from task runner (with "gulp-nuget-restore": "^0.7.0"), it's failing to authenticate to my feed. What am I missing?
If you want install NuGet package from azure devops artifacts, you should add a nuget.config file to your project, in the same folder as your .csproj or .sln file. Please check this document for more information. Then you can use nuget restore task
If it is a npm package, you should use npm install task.
If you are using the feed from azure devops pipeline. You also need to check if your project build service account have the reader permission to this feed. Please check below steps.
Click the Feed Setting(the gear icon)--> go to Permissions --> Check if group {projectName} build service(OrganizationName) has the permission(Click add groups to add your project build service account if not already existed).
Please refer to 'npm' task in ADO - https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/package/npm?view=azure-devops to install and publish npm packages. Hope this helps
We actually found two ways of resolving this in the end.
One was to use the gulp-nuget task instead, to download a specific version of Nuget.exe (5.0.2) which would then allow us to subsequently run the restore (as I believe that version of Nuget uses the credential provider by default).
The other (which we ended up going with) was to add
overrideParams.push('/p:NuGetInteractive=true')
to the msbuild task. This will prompt users to log in if not authenticated.
The CI pipeline works well if I remove the nobuild:true option from the DotNetCoreCLI#2 task to pack the Project (ie to create a NuGet package) but I am not able to understand what special except not building the project does the nobuild option brings.
I need not want to build the Project again as the Previous task have already build the Project and locked the Assembly version of DLLs generated. I want to use the same build to create the NuGet package and to do the same I need to pass the NoBuild option but doing the same breaks the pipeline.
The pipeline gives the error that the DLLs to be packed are not present at the specified location but I tried to look at the location and I could find the DLLs.One thing that confuses me is that though I have given nobuild to be true but still the tasks shows as Building the Project.
- task: DotNetCoreCLI#2
displayName: ".NET pack"
inputs:
command: pack
packagesToPack: ${{ parameters.packagesToPack }}
nobuild: true
versioningScheme: byEnvVar
versionEnvVar: CI_Version
packDirectory: $(build.artifactStagingDirectory)\${{ parameters.packTo }}
verbosityPack: 'Normal'
Its also important to note that the same thing( nobuild:true) works on Windows Agent but it fails on Ubuntu Agent.
PS: It could be a case where windows has upgraded the agent and has caused the issue. I searched over the issue and found that one has to lock the .net SDK in the build pipeline
Thanks for the other answers that may be related to the issue but things were already taken care.
The issue was only on the Linux Environment because of an issue in .NET SDK. Refer here
The error(DLLs could not be found in the path specified ) that was being generated was correct in somehow but also it was misleading. The DLLs were being generated in Release folder at the build stage and when I was packing the DLLs they were being searched in release folder.
Though Release and release remains the same in Windows Environment but Ubuntu being case sensitive generates the Error.
The SDK implementation of .Net Core missed the IgnoreCase in the Regex option and that caused the build to break on switchin to a Linux Agent.
DotnetBuild:
Dotnet Pack:
Solution: Define the folder where to generate the DLLs in the .csproj and the automatically build and pack step would pick the DLLs from there.
For this error NU5026 ,it refers to the project being packed has not been built yet and hence cannot be packed. Please view this reference.
The file ''F:\project\bin\Debug\net461\project.exe' to be packed was not found on disk.
According to your description, you canceled the automatic build before pack. There's possibility that your build task and pack task did't run with same configuration. For example, In dotnet build task, the project is automatically built with Debug configuration, and in the pack task you set the configuration as Release.
In dotnet build task, the project is automatically built with Debug configuration.
In the dotnet pack task , the default Configuration to Package is Release
If you do not cancel the automatic build before pack, in the .net pack task the project is built in Release configuration.
So please check the log of your build task and pack task, make sure the dotnet build command and dotnet pack command use the same configuration.
I have created a build pipeline which works correctly and publishes artifacts at the end.
I also created a release pipeline to deploy the REST API to Azure web app
The release pipeline task has this information:
$(System.DefaultWorkingDirectory)/**/*.zip
However I get this error:
Error: More than one package matched with specified pattern: D:\a\r1\a\**\*.zip. Please restrain the search pattern.
When I see the drop folder, I can indeed see that there are folders by date and there are several .zip files
The webapi is in the drop root, but also in the shown folder.
I havent been able to find how to clean the entire drop folder each time, or how to avoid this error.
Update 1:
In the build pipeline I can see when publishin this:
##[section]Starting: Publish Artifact: webapidrops
==============================================================================
Task : Publish Build Artifacts
Description : Publish build artifacts to Azure Pipelines/TFS or a file share
Version : 1.142.2
Author : Microsoft Corporation
Help : [More Information](https://go.microsoft.com/fwlink/?LinkID=708390)
==============================================================================
##[section]Async Command Start: Upload Artifact
Uploading 31 files
Uploading 'webapidrops/2019_04/04_06_58/LuloWebApi.zip' (16%)
Uploading 'webapidrops/LuloWebApi.zip' (16%)
Uploading 'webapidrops/LuloWebApi.zip' (33%)
Uploading 'webapidrops/LuloWebApi.zip' (50%)
Uploading 'webapidrops/LuloWebApi.zip' (66%)
Uploading 'webapidrops/LuloWebApi.zip' (83%)
Uploading 'webapidrops/LuloWebApi.zip' (100%)
File upload succeed.
Upload 'D:\a\1\a' to file container: '#/1483345/webapidrops'
Associated artifact 387 with build 125
##[section]Async Command End: Upload Artifact
##[section]Finishing: Publish Artifact: webapidrops
The zip files are came from your build pipeline. if you need only the LuloWebApi.zip so configure your build pipeline publish artifacts task to take only this.
If you need also the second zip for your release so you can specify the LuloWebApi.zip in your release:
$(System.DefaultWorkingDirectory)/**/LuloWebApi.zip
Or, you mentioned that the zip also exist in the date folder so specify this folder:
$(System.DefaultWorkingDirectory)/**/**/*.zip
My issue was I had an MVC Project and an API Project in the same solution - Creating a POC.
I deleted the MVC project (via Visual Studio). However, the physical files were still part of source control.
When deploying (via Azure DevOps) it still had both projects as part of the artifacts and threw that error.
PreInfo: I have .net core web api (vs2015) mixed with just ordinary projects.
I have spent almost 2 days now to get this to work and search and tried everything I can think of, but I just cant for the live of me get the build and release in TFS online to play together.
The build (publish artifact step) says "Directory 'D:\a\1\a' is empty. Nothing will be added to build artifact 'drop'."
but the "run dot net" step says
"Published to D:\a\1\s\Operator\MobileService\root\MobileService\src\AMP.Operator.MobileService\bin\release\net452\win7-x64\publish"
...so it must be somewhere the release can pick it up but no matter what I try I can´t get it to be picked up.
Here is my build setup
dotnet run
publishing
And the realse with $(System.DefaultWorkingDirectory)/MobileService-Dev please note that I have tried every combo of $(build.artifactstagingdirectory) in the build to publish without luck but I sure this should point to the publishing folder for the build
I so hope somebody can point me to a solution. I just can´t understand how hard it is to make this work..
Within your build definition, I recommend adding a Copy Files step that will copy your the build artifacts from your msbuild results to the Build's Artifact Staging Directory before you run the Publish Artifact step.
Source Folder: $(Build.SourcesDirectory)
Contents: **\bin\$(BuildConfiguration)\**
Target Folder: $(Build.ArtifactStagingDirectory)
I am assuming that the $(BuildConfiguration) variable is custom to your definition and is probably Debug or Release. I am not sure what exactly the Run dotnet step does, but this build definition I setup published my build artifacts correctly. The Publish Build Artifacts step I'm running has the same steps as yours, except the only control option enabled is Enabled.
I am also running on TFS 2015 update 2.
You can download the files if you just want to take a look at them. Go to the build, click on the Artifacts tab, and then download as shown below:
You need to specify output argument (--output/-o) for dotnet publish command.
Arguments:
Publish -c $(BuildConfiguration) -o $(Build.ArtifactStagingDirectory)
BTW: You said “run dot net” step says “Published to D:\a\1\s....”, the files are in D:\a\1\s, no files in D:\a\1\a (one is s and another is a).