I'm pretty new on all AZURE devops.
I did just the minimal install on my VS solution, nuget Gitversiontask in my solution, push to Azure Git pipeline and it worked with the development branch.
I created ( GitFLOW) a feature named dostuff.
Made some changes on classes, then commit & push...
Version feature/my-app 6.1.0-dostuff0001came out ...Nuget pack and push... all fine.
Then did an another commit, pipeline start but at Nuget Push to artifacts ...ERROR 409 (Conflict - The feed already contains 'my-app 6.1.0-dostuff0001).
pipeline
- task: NuGetCommand#2
displayName: 'restore WinFormExtC.sln'
inputs:
restoreSolution: WinFormExtC/ActiveFramework.WinFormExtC.sln
feedsToUse: config
nugetConfigPath: NuGet/NuGet.Config
steps:
- task: VSBuild#1
displayName: 'Build solution WinFormExtC'
inputs:
solution: WinFormExtC/ActiveFramework.WinFormExtC.sln
platform: '$(BuildPlatform)'
configuration: '$(BuildConfiguration)'
steps:
- task: NuGetCommand#2
displayName: 'NuGet pack WinFormExtC'
inputs:
command: pack
packagesToPack: WinFormExtC/Package.nuspec
versioningScheme: byEnvVar
versionEnvVar: GitVersion.NuGetVersion
includeSymbols: true
Your build pipeline references an undefined variable named ‘Parameters.searchPatternPush’. Create or edit the build pipeline for this YAML file, define the variable on the Variables tab. See https://go.microsoft.com/fwlink/?linkid=865972
steps:
- task: NuGetCommand#2
displayName: 'NuGet push'
inputs:
command: push
packagesToPush: '$(Parameters.searchPatternPush)'
publishVstsFeed: '505cb4b9-0633-4d83-b4b6-1e5fc7ad020f'
Question: How can I get the my-app 6.1.0-dostuff0001 increase or change when I queue the pipeline in Azure devops and the build task increment the version of feature branch?
Please remember that I'm new to all this Build, yml, config etc. concept.
Why is my version not incrementing?
GitVersion calculates the semantic version, this will only change once per release. Read more at
version increments
So, to make it incremental we can set and use a config file : GitVersion.yml. Below GitVersion.yml for your reference, it works for me when trigger from master branch.
mode: Mainline
tag-prefix: '[vV]'
commit-message-incrementing: MergeMessageOnly
branches:
feature:
regex: feature?[/-]
source-branches: ['develop']
release:
increment: Minor
regex: release?[/-]
develop:
is-mainline: true
increment: Patch
regex: develop$
master:
regex: master$
More GitVersion related info please reference the following blogs:
Azure DevOps pipelines with YAML and GitVersion
Effective Nuget Package Versioning in Azure DevOps with Git Tags and
GitVersion
Related
Because Azure AppServices doesn't (anymore) support .NET Core 2.1 on x64 with framework-dependent deployments, we are currently publishing self-contained win-x64 versions of our .NET Core 2.1 Web API.
I'm trying to setup an Azure Pipeline in Yaml for CI/CD purposes and deploy it to Azure App Service deployment slot.
The issue I'm trying to resolve is this error-message: project.assets.json' doesn't have a target for 'netcoreapp2.1/win10-x64'
/usr/bin/dotnet publish /home/vsts/work/1/s/MyApp.WebApi/MyApp.WebApi.csproj --configuration Release -f netcoreapp2.1 -r win10-x64 --self-contained true --no-restore --output /home/vsts/work/1/a/MyApp.WebApi
Microsoft (R) Build Engine version 16.8.3+39993bd9d for .NET
Copyright (C) Microsoft Corporation. All rights reserved.
/usr/share/dotnet/sdk/5.0.102/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(241,5): error NETSDK1047: Assets file '/home/vsts/work/1/s/MyApp.WebApi/obj/project.assets.json' doesn't have a target for 'netcoreapp2.1/win10-x64'. Ensure that restore has run and that you have included 'netcoreapp2.1' in the TargetFrameworks for your project. You may also need to include 'win10-x64' in your project's RuntimeIdentifiers. [/home/vsts/work/1/s/MyApp.WebApi/MyApp.WebApi.csproj]
##[error]Error: The process '/usr/bin/dotnet' failed with exit code 1
This is my yaml file:
# ASP.NET Core
# Build and test ASP.NET Core projects targeting .NET Core.
# Add steps that run tests, create a NuGet package, deploy, and more:
# https://learn.microsoft.com/azure/devops/pipelines/languages/dotnet-core
trigger:
- develop
pool:
vmImage: 'ubuntu-20.04'
variables:
buildConfiguration: 'Release'
buildPlatform: x64
steps:
- task: DotNetCoreCLI#2
displayName: dotnet restore
inputs:
command: 'restore'
projects: '**/*.csproj'
feedsToUse: 'config'
nugetConfigPath: './NuGet.config'
externalFeedCredentials: 'Hangfire Pro'
- task: DotNetCoreCLI#2
displayName: dotnet publish
inputs:
command: 'publish'
publishWebProjects: true
feedsToUse: 'config'
nugetConfigPath: './NuGet.config'
externalFeedCredentials: 'Hangfire Pro'
arguments: '--configuration $(BuildConfiguration) -f netcoreapp2.1 -r win10-x64 --self-contained true --no-restore --output $(build.artifactstagingdirectory)'
# this code takes all the files in $(Build.ArtifactStagingDirectory) and uploads them as an artifact of your build.
- task: PublishBuildArtifacts#1
inputs:
pathtoPublish: '$(Build.ArtifactStagingDirectory)'
artifactName: 'MyAppWebApi'
I tried modifying the CSPROJ file by adding these:
<PropertyGroup>
<TargetFramework>netcoreapp2.1</TargetFramework>
**<RuntimeIdentifiers>win10-x64;win-x64</RuntimeIdentifiers>**
and
<PlatformTarget>x64</PlatformTarget>
Please delete the obj and bin folders from your project. Also the <TargetFramework> in your .csproj file was singular. Please try to add an "s" and it become "TargetFrameworks" to see if it works.
<PropertyGroup>
<TargetFrameworks>netcoreapp2.1</TargetFrameworks>
<RuntimeIdentifier>win-x64</RuntimeIdentifier>
</PropertyGroup>
You could refer to this thread for more possible solutions.
BTW, there are different build environment between Microsoft-hosted Windows-2019 agents(which install Visual Studio Enterprise 2019) and your local machine, you could try to use self-hosted Windows agents to build your project without additional environment preparation steps.
A few things went wrong during my work. The most important one is that all the changes I've tried to make were pushed to the Develop-branch while the Pipeline was running on a different branch. My inexperience with Pipelines (and also Git) mainly caused this. I was under the impression that the trigger line in YAML pointed to the repository to restore and publish.
I finally got it working with the following steps. Like Edward Han mentioned, I tried to restore and publish by command line on my local machine. These also gave me some errors I needed to fix. Like adding this line to all (30+) referenced csproj files:
<TargetLatestRuntimePatch>true</TargetLatestRuntimePatch>
Then add this configuration to the webproject csproj:
<RuntimeIdentifiers>win-x64</RuntimeIdentifiers>
Then my final YAML file is this:
trigger:
- develop
pool:
vmImage: 'windows-2019'
variables:
buildConfiguration: 'Release'
buildPlatform: x64
steps:
- task: UseDotNet#2
displayName: 'Use .Net Core sdk 2.1.x'
inputs:
version: 2.1.x
- task: DotNetCoreCLI#2
displayName: dotnet restore
inputs:
command: 'restore'
projects: '**/*.csproj'
arguments: '-r win-x64'
feedsToUse: 'config'
nugetConfigPath: './NuGet.config'
externalFeedCredentials: 'Hangfire Pro'
- task: DotNetCoreCLI#2
displayName: dotnet test
inputs:
command: 'test'
projects: '**/*[Tt]ests/*.csproj'
arguments: '--configuration $(BuildConfiguration)'
testRunTitle: 'dotnet test 2'
- task: DotNetCoreCLI#2
displayName: dotnet publish
inputs:
command: 'publish'
publishWebProjects: true
arguments: '--configuration $(BuildConfiguration) -r win-x64 --self-contained true --no-restore --output $(build.artifactstagingdirectory)'
# this code takes all the files in $(Build.ArtifactStagingDirectory) and uploads them as an artifact of your build.
- task: PublishBuildArtifacts#1
inputs:
pathtoPublish: '$(Build.ArtifactStagingDirectory)'
artifactName: 'MyAppWebApi'
Few important things I changed/added:
Explicitly tell to use .NET Core 2.1.*
Add -runtime parameter to the RESTORE command
Conslusion
Although I studied some Pluralsight courses, YouTube video's and blogs, I still ended up reading the Microsoft Docs/MSDN. Being used to use publishing by the Visual Studio User Interface, switching to command-line really was a big difference. A lot more depencenies are needed to be looked at. Tip: really read the urls these error messages provide, they do contain enough information to resolve your issue. At least, that's what I learned.
i have an issue with azure task in ci/cd,
each release have an tests task that run before code deployed, and each time all solution build and it's take time.
i want that only specific project that related to the release will build and not all the solution.
how can i fix it?
According to your SO tags, it seems that you're using C#.
To build one specific project that targets .net framework in build task:
You should use MSBuild task instead of Visual Studio Build task.
To build one specific project that targets .net core/standard in build task:
You should use Dotnet build with this kind of input:
Also if you're using Dotnet test in release task, it will automatically build the projects to test unless you add the --no-build switch. So you also need to make sure you're specifying specific project to test instead of using **/*.csproj.
trigger:
branches:
include:
- master
pool:
name: Azure Pipelines
vmImage: 'windows-2019'
demands:
- msbuild
- visualstudio
variables:
BuildConfiguration: "Release"
platform: any cpu
BuildPlatform: any cpu
name: 1.$(build.buildid)
stages:
- stage: Build
jobs:
- job: Build
steps:
- task: NuGetToolInstaller#0
displayName: 'Use NuGet 4.4.1'
inputs:
versionSpec: 4.4.1
- task: NuGetCommand#2
displayName: 'NuGet restore'
inputs:
restoreSolution: 'path to sln file/xxxxxxx.sln'
vstsFeed: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
- task: VSBuild#1
displayName: 'Build solution'
inputs:
solution: 'path to sln file/xxxxxxx.sln'
platform: '$(BuildPlatform)'
configuration: '$(BuildConfiguration)'
clean: true
Also, check-in Pipeline at the initial step if the respective sln file is selected
I am trying to deploy my code from Azure to my local machine. The steps I followed:
Created deployment group
Run register script on my machine(the folders successfully created in C:\azagent)
Created pipeline.
For pipeline the generated YAML is:
# ASP.NET
# Build and test ASP.NET projects.
# Add steps that publish symbols, save build artifacts, deploy, and more:
# https://learn.microsoft.com/azure/devops/pipelines/apps/aspnet/build-aspnet-4
trigger:
- master
pool:
vmImage: 'windows-latest'
variables:
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
steps:
- task: NuGetCommand#2
inputs:
command: 'restore'
restoreSolution: '**/*.sln'
feedsToUse: 'select'
vstsFeed: 'a31f9237-4431-41f2-b1a9-4370c7dc4828/a3a86133-79b3-437a-bc19-9665a420de4e'
- task: VSBuild#1
inputs:
solution: '**\*.sln'
msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactStagingDirectory)"'
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
restoreNugetPackages: true
- task: CopyFiles#2
inputs:
SourceFolder: '$(build.sourcesdirectory)'
Contents: '**\bin\$(BuildConfiguration)\**'
TargetFolder: '$(build.artifactstagingdirectory)'
CleanTargetFolder: true
OverWrite: true
- task: PublishBuildArtifacts#1
inputs:
PathtoPublish: '$(Build.ArtifactStagingDirectory)'
ArtifactName: 'drop'
publishLocation: 'Container'
When I run the pipeline, it doesn't give any error but in release part I get an error:
The solution I am using has multiple projects. I need to deploy three projects on my machine. This is the first time I am using Azure DevOps and I don't have any clue about the error. Online articles are mostly explaining about cloud deployment and I could not find much about on-premise. In short my requirement is to deploy three projects from my repo on my local machine whenever I push any changes to master branch. Is there any step by step guide to achieve the same? What is the step I missed in the setup? Any help is much appreciated.
According to the description of the error message, first you need to check whether the corresponding build pipeline is selected as the release artifact source.
Then you can check whether the download artifacts path is consistent with the file path to the package(Package or Folder) of the IIS web app deploy task.
System.DefaultWorkingDirectory : The directory to which artifacts are downloaded during deployment of a release. The directory is cleared before every deployment if it requires artifacts to be downloaded to the agent. Same as Agent.ReleaseDirectory and System.ArtifactsDirectory.
Example: C:\agent\_work\r1\a
For details, please refer to predefined variables document.
my requirement is to deploy three projects from my repo on my local
machine whenever I push any changes to master branch.Is there any step by step guide to achieve the same?
To achieve this , in yaml build pipeline ,you need to set CI trigger: Continuous integration (CI) triggers cause a pipeline to run whenever you push an update to the specified branches.
In release pipeline , you need to set build pipeline as release artifact source, and then enable Continuous deployment trigger: This instructs Azure Pipelines to create new releases automatically when it detects new artifacts are available.
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'
For a given project, I have four build pipelines, each pipeline Trigger has CI enabled, each has a branch filter for a single branch - master, Staging, QA, development. These work successfully, any completed pull request to one of those four branches are successfully kicking off a build process.
This morning, I created a new branch based off "development" branch. IT was a one-liner change, so I decided to make the change online in the browser using DevOps editor. I saved the change.
Immediately after saving the change online, I saw a new build pipeline was created (I had received an email saying my build failed). What caused the new Build pipeline to be created?
The new build pipeline looks to be auto-created, it is pure YAML:
pool:
vmImage: 'Ubuntu 16.04'
variables:
buildConfiguration: 'Release'
BuildPlatform: 'Any CPU'
Parameters.solution: = '*.sln'
Parameters.ArtifactName: = 'xxxxxx'
steps:
- task: NuGetToolInstaller#0
displayName: 'Use NuGet 4.4.1'
inputs:
versionSpec: 4.4.1
- task: NuGetCommand#2
displayName: 'NuGet restore'
inputs:
restoreSolution: '$(Parameters.solution)'
- task: VSBuild#1
displayName: 'Build solution'
inputs:
solution: '$(Parameters.solution)'
platform: '$(BuildPlatform)'
configuration: '$(BuildConfiguration)'
- task: PublishSymbols#2
displayName: 'Publish symbols path'
inputs:
SearchPattern: '**\bin\**\*.pdb'
PublishSymbols: false
continueOnError: true
- task: PublishBuildArtifacts#1
displayName: 'Publish Artifact'
inputs:
PathtoPublish: '$(build.artifactstagingdirectory)'
ArtifactName: '$(Parameters.ArtifactName)'
In the project, there were no pull requests created, and my private branch, I can see my change.
The email I received had this in the title (actual names removed):
[Build failed] MyProjectName CI - MyProjectName:MyBranchName - MyProejctName - bf9524f9
========
EDIT
I just found there is an azure-pipelines.yml file in the root folder of the branch. the contents match the above. Is this competing with the designer pipelines?
Yaml pipelines are better at scale, you can manage them in a central place, you can easily make mass edits and\or you can make them depend on each other to have more control. Visual designer is only good when you have couple of pipelines or you are only getting started with the whole pipelines thing.
Yaml pipelines do not necessary have to be in azure-pipelines.yml file. I store them in a separate repo :)
Updated comment:
Also the fact that there are no triggers added in your yaml mean that every new branch will queue builds. Read about 'trigger' on the yaml schema to get more understanding on this.
You can use something like below;
trigger:
branches:
include:
- master
- develop
exclude:
- no-build-branch
Given that there is none defined is behaves as below;
trigger:
branches:
include:
- '*'
These two are the same....
Designer picks the azure-pipelines.yml when you click edit. This is the default file name that gets picked up automatically to create a pipeline.
E.g. if you add the pipeline source to azure-pipelines.yml and commit/push it will automatically create a pipeline named 'Repo_Name CI' and queue a build as well.
Any new changes will work on it's merits as per the yaml definition.
you can always use different names and add as many pipelines you want as well.....