I have uploaded a package that is being used by multiple pipelines. Some pipelines in some projects get the latest version and some pipelines in some projects do not. The key here is they all share the same pipeline template so I'm not quite sure where the problem may be or where to start looking. The call being made is:
install ${{ parameters.NugetPckDefinition }} -ExcludeVersion -NoCache -OutputDirectory "$(Build.SourcesDirectory)"
The versions are the following:
1.0.3169
1.0.3009
Some pipelines are getting 1.0.3169 and some are downloading 1.0.3009. Currently, in order for those pipelines that cannot get the latest version, I call the REST API to get the specific package so that it will show up in Azure Artifacts.
I suspect there are some permissions issues or possibly some caching issues, but the pipelines share the same Build Service account. I checked the permissions on the Agent Pool and they all have the same settings.
Related
a month ago we had a solution (big one) in .net framework 4.7.2. This was building fine on azure devops pipeline.
Now we ported our solution to net5.
Everything is working in visual studio but on azure devops, the pipeline is failing.
We had to change our Microsoft.Interop.Word (and excel, and outlook) to a com reference. Because net5 is multiplatform and interop is not.
Because we removed the nuget packages and changed to com reference the pipeline is failing.
Does anyone know how to handle this specific problem?
We can't remove the interop.excel and etc from our projects because they are dependent on it.
Beneath you see the result we have.
It feels like we have tried everything to make it work again on azure devops.
have you consider self-hosted agent since you have requirement to stay the external library in this case Microsoft.Office.Interops and I don't think Microsoft Azure DevOps Pipeline agent support that currently.
With self-hosted agent, you install the PIAs and link your library/com references to the paths.
There is problem with assembly in the code, your code may be building on local environment as it is getting references for all assemblies however when you checking in the code pipelines could not fetch the assemblies through nuget package restore, if you are referencing assembly from local machine, make sure you add its nuget package reference package.config file, so nuget restore will restore the package
can you try below
Link
I am looking for practical options to develop and test private nuget packages.
We have a set of "core" code that is delivered securely through an Azure Artifact Feed. We have various "consuming" applications that use the core nuget packages.
As a small-medium team, one person may be developing the core nuget as well as consuming it.
Today we check-in / merge the code for the nuget package. Make sure the Pull request is approved / passes. Then the build updates the Azure Artifact feed.
Then we come back to the "consuming" app and can update the package. Works great if you fix / add the feature the first time. However, slows down productivity when treating this as an iterative development approach.
Looking for simple options for a small team. Random thoughts on options:
Push nuget "alpha" package straight from developer's machine to Azure Artifact feed. Symbol server too?
Do something with an Azure build to allow "feature" branches to publish to Azure Artifact feed somehow?
Push to local nuget feed. Include pdbs so it can be debugged?
Temporarily break the nuget reference directly for local copy of dll(s)?
Re-think using nuget packages as a whole?
Push nuget "alpha" package straight from developer's machine to Azure Artifact feed. Symbol server too?
It depends on whether you need to debug it. If you need do debug this "alpha" package, you have to push the symbol package to the symbol server.
Note: You do not need to push the "alpha" package to the symbol server, just the symbol package.
Do something with an Azure build to allow "feature" branches to
publish to Azure Artifact feed somehow?
There is a task Push NuGet packages, we could use it to publish to Azure Artifact feed during build, no matter which branch it is on. It depends on whether you have enough permissions for the Azure Artifact feed, you can check it from Artifacts->Settings->Feed settings->Permissions:
Push to local nuget feed. Include pdbs so it can be debugged?
No, you also have to include the source code. Check this thread for some more details.
And there is a lightweight solution how to debugged nuget package on local feed on a network share.
Temporarily break the nuget reference directly for local copy of
dll(s)?
Re-think using nuget packages as a whole?
The answer is yes, when we develop the project on the local, use project reference is better than nuget, check my another post for some more details:
Ticket: Project reference VS NuGet.
Hope this helps.
I have an Azure DevOps project (just one).
I have a Build Pipeline set to run in the "Hosted VS2017" Agent Pool. This Agent Pool appears to be in the [MyProject]\Build Administrators, Contributors, Project Administrators, and Release Administrators roles.
I also have an Artifacts nuget feed in the DevOps project. It has [MyProject]\Project Valid Users set as "Reader" role. It appears that Project Valid Users has all of the Agent Pool's roles mentioned above as members.
I have an azure-pipelines.yml script that adds that adds the artifacts feed as a nuget source right at the beginning:
# Add nuget source
- powershell: Invoke-RestMethod "https://dist.nuget.org/win-x86-commandline/latest/nuget.exe" -OutFile "$env:UserProfile/nuget.exe"
- script: '%UserProfile%\nuget.exe sources Add -Name "devops" -Source "https://pkgs.dev.azure.com/MyProject/_packaging/feed/nuget/v3/index.json"'
The build yml then dot a dotnet build but fails inside NuGet.targets with:
Unable to load the service index for source https://pkgs.dev.azure.com/MyProject/_packaging/feed/nuget/v3/index.json.
Response status code does not indicate success: 401 (Unauthorized).
how can I make this work? My build needs packages from other builds that are on that artifacts feed...
There is a better alternative imo. You can continue using your script to dotnet restore.
Simply add a task just before that with NuGetAuthenticate#0
steps:
- task: NuGetAuthenticate#0
- script: dotnet restore --no-cache --force
this task will authenticate the pipeline with the nuget feeds that require so and are found at the NuGet.config file.
More info here
Notice that when the nuGet feed is within Azure DevOps there is nothing else required. If the feed is external you can configure at your Azure DevOps a nuGet Service Connections (at the link there is further info).
Use the built-in tasks for installing and running NuGet and you won't have authentication problems.
Use the dotnet task's restore command. If you're using a single Azure Artifacts feed, just select it from the dropdown in the task (instead of the PowerShell you mentioned). If multiple feeds (doesn't look like it from your question, but just in case), you'll need to check in a NuGet.config that references all of those feeds, then point the task to that config.
You may also need to pass the '--no-restore' flag to your 'dotnet build' command.
If you still encounter issues, ensure the correct build identity has access to your feed.
We are building packages for multiple deployment environments using TeamCity server and OctoPack. The problem is that tentacle agent chooses the latest by number version of the package, so it's the same (latest) package that is deployed on all environments. Here's the summary of our setup:
Environments DEV and STAGE;
Deployment to DEV is triggered from Git "dev" branch;
Deployment to STAGE is triggered from Git "stage" branch;
OctoPack is configured to generate packages MyProduct.1.0.0.dev-%build_counter% for DEV build configuration;
OctoPack is configured to generated packages MyProduct.1.0.0.%build_counter% for STAGE build configuration;
TeamCity is configured to expose OctoPack artefacts (NuGet packages) via its NuGet feed;
Octopus project is configured to deploy packages with NuGet Id MyProduct from TeamCity NuGet feed.
So what happens is that since DEV builds are run more frequently, they have larger %build_counter%, and STAGE doesn't get a chance to get a deployment of its own packages - Octopus tentacle preferes packages with 1.0.0.dev-* suffix.
This must be fairly common scenario, but I haven't found a simple way to solve it.
There are some parts that are not documented here: https://github.com/OctopusDeploy/Octopus-Tools. But if you look at https://github.com/OctopusDeploy/Octopus-Tools/blob/master/source/OctopusTools/Commands/CreateReleaseCommand.cs it is possible to figure out what you can do.
I think the tools is backward compatible, but not 100 % sure about that.
When you are using the octo tools, which I expect that you use, you can set the version (also called releasenumber now) option to specify the release number. If you doesn't specify anything else it will take the latest package so what you want to do is set the packageversion (also called defaultpackageversion now) that should be used for the release.
I think that should do it. If it doesn't, what are you using to create the release?
Example of what we are using from our TeamCity when using octo tools which we have added to the environment path on the build agents:
create-release --server=%conf.OctoServerApi% --project=%conf.OctoProject% --version=%env.OctopusPackageVersion% --deployto=%conf.OctoDeployEnv% --packageversion=%env.OctoPackPackageVersion% --apiKey=%conf.OctoApiKey% --waitfordeployment %conf.OctoExtraParams%
UPDATE:
The documentation for 2.0 is much better: http://docs.octopusdeploy.com/pages/viewpage.action?pageId=360596
Inspired by Tomas Jansson's answer, simply adding the following to Additional command line arguments in the OctopusDeploy: Create release build step (TeamCity v9) worked for me:
--packageversion=%build.number%
Not every time but quite frequently I get ##[error]The nuget command failed with exit code(1) and error(NU1102: Unable to find package MyPackage with version (>= 1.0.5)
in my Azure Pipelines builds (different packages and different versions):
The package definitely exists as it had just been built a couple of minutes ago and I can see it in the Artifact Feed:
Here is my pipeline:
The project consists of multiple packages so this is starting to get really inconvenient. If I try on different build agents I eventually get one to work but the pipelines are supposed to be more of a hands off process. As far as I can tell (or guess), Nuget is caching the index.json for the feed. The only other issues I can find related to this specifically happen in people's local environments. Is there some way to get Nuget to properly check if packages exist?
1.Not sure about the real cause of your issue, but if cleaning cache can help to resolve your issue, you only need to enable this option in Restore task.
2.Also, sometimes the package not found error could be related to feed permissions in Devops. Go Artifacts=>custom Feed=>Feed Settings in right corner:
Make sure your build service have access to that feed.
NuGet does cache what versions of a package are available on each feed for 30 minutes, so the package was published more recently than that, and that machine had already restored a different version of the package within the last 30 minutes, it will be a problem.
You could run dotnet nuget locals http-cache --clear or nuget.exe locals http-cache -clear before the restore, that will delete NuGet's HTTP cache.