We're using NB.GV in our CI pipeline like:
- task: DotNetCoreCLI#2
inputs:
command: custom
custom: tool
arguments: install --tool-path . nbgv --ignore-failed-sources
displayName: Install NBGV tool
- script: nbgv cloud -c -a
displayName: Set Version
It sets the version correctly, so in further tasks, we're able to use them (e.g. $(GitBuildVersion))
The problem comes when we're trying to setup a CD pipeline based on this article. There we need to read $(Build.BuildNumber) which has a different value than expected. Based on official documentation it should be e.g. 1.3.1.57621 but we're getting 1.3.1+g15e1898f47.
It seems like AssemblyInformationalVersion and BuildVersion got exchanged.
We have set setVersionVariables: true in version.json.
Thanks for any help in advance
You my add this after running ngbv to update you BuildNumber
- powershell: Write-Host "##vso[build.updatebuildnumber]$(GitBuildVersion)"
displayName: 'Update build number to $(GitBuildVersion)'
According to this you should have then expected value:
You may also check what variables you have by running - bash: env | sort
Related
I am trying to use an Azure DevOps deployment job to create a ServiceNow Standard Change Request, register the sys_id to the pipeline, then use it in subsequent phases of the Deployment Job. I have a Python utility that creates a Change Request, and filters the sys_id registering it as a variable. I can access said variable in the same "phase" of the Deployment Job, but the next phase is not working as expected, well,the docs don't really cover any use like this other than contrived uses. I think I was following the Set Variables in Scripts See my pipeline below.
- task: Bash#3
name: snow
displayName: Create Standard RFC from Template
# This task, I'm registering the SYS_ID of the RFC being created. I want to use this throughout the rest
# of the Deployment Job.
inputs:
targetType: inline
script: |
export sys_id=$(servicenow standard create template $(std_tmpl_sys_id) --query="result.sys_id.value")
echo "##vso[task.setvariable variable=rfc_sys_id;isoutput=true]$sys_id"
env:
SNOW_USER: '$(SNOW_USER)'
SNOW_PASS: '$(SNOW_PASS)'
- task: Bash#3
displayName: Progress RFC to Scheduled
# This works, for this one task.
inputs:
targetType: inline
script: |
servicenow standard update $(snow.rfc_sys_id) state=Scheduled
env:
SNOW_USER: '$(SNOW_USER)'
SNOW_PASS: '$(SNOW_PASS)'
deploy:
steps:
- task: Bash#3
displayName: Install ServiceNow
inputs:
targetType: inline
script: |
pip install snow --index-url=https://azure:$(System.AccessToken)#pkgs.dev.azure.com/$(ADO_ORG)/$(ADO_PROJ)/_packaging/python-azure-artifacts/pypi/simple/
- task: Bash#3
displayName: Progress RFC to Implement
# Here, I attempt to get the registered variable from the preDeploy "phase" and use it as a Shell Variable
# because otherwise Azure DevOps would try to just execute it as a shell command.
inputs:
targetType: inline
script: |
servicenow standard update ${RFC_SYS_ID} state=Implement
env:
SNOW_USER: '$(SNOW_USER)'
SNOW_PASS: '$(SNOW_PASS)'
RFC_SYS_ID: $[ dependencies.BuildPythonApp.outputs['preDeploy.rfc_sys_id'] ]
Also found here:
https://gist.github.com/FilBot3/d8184b3c0b1c887e7e99884b051bd73c#file-azure-pipelines-yaml-L89-L131
Is it even possible to do this in Azure DevOps YAML Pipelines using a Deployment Job?
Can you try two of them? I think only the step-name is missing.
RFC_SYS_ID: $[ dependencies.BuildPythonApp.outputs['preDeploy.snow.rfc_sys_id'] ]
or
RFC_SYS_ID: $[ dependencies.BuildPythonApp.outputs['BuildPythonApp.snow.rfc_sys_id'] ]
I am trying this for quite sometime now & not able to figure out how to proceed further. My requirement is to dynamically calculate a variable in a bash task & then in next step use the same as a parameter to the gulp task. Below are my two tasks as part of the build pipeline (removed lines for simplicity)
- task: Bash#3
name: SetVariableValue
inputs:
targetType: inline
script: >
// removed
myvariableValue=$(do something & calculate here, assume value will be 'abc')
// Set to an output variable
echo "##vso[task.setvariable variable=myVar;isOutput=true]$myvariableValue"
- task: gulp#0
displayName: Publish front-end
inputs:
gulpFile: $(Build.SourcesDirectory)/../gulpfile.js
targets: publish
arguments: >-
--buildId $(Build.BuildId) --buildNumber $(Build.BuildNumber) --sourceBranch $(Build.SourceBranch) --var $(myVar)
gulpjs: >-
$(Build.SourcesDirectory)/../node_modules/gulp/bin/gulp.js
enableCodeCoverage: false
I am using linux machines to build angular packages and the gulp publish command is used to package our code depending on the said variable.
With above steps all the rest parameters like BuildId, BuildNumber, SourceBranch are getting passed correctly but the 'var' parameter is being passed as $(myVar) only, rather abc
Can you please help me on what am I missing here? I tried multiple things like --var $(Build.myVar), but not able to make it work.
Thanks
Sanjay
Oh man all I needed was to correct the name of the step & refer it without mistyping :(
--var $(SetVariableValue.myVar) did the trick. Thanks.
I'm working with Azure DevOps and I need to set the return of bash commands into some variables, for example I have the following:
variables:
VERSION: 7.2 # works fine
FILE_VERSION: ${{cat public/VERSION}} # syntax error
I tried some some variations from ${{}} without success and I could not found the right syntax for it, but I think it must be possible.
You should use a bash step for that.
Like this:
steps:
- bash: |
echo "##vso[task.setvariable variable=FILE_VERSION]$(cat public/VERSION)"
You need to do this in two steps
STEP 1: Set static value first
variables:
VERSION: 7.2
STEP 2: Create step to calculate the value
Note this will only be available for subsequent steps
- bash: |
FILE_VERSION="$(cat public/VERSION)"
echo "##vso[task.setvariable variable=FILE_VERSION]$FILE_VERSION"
Resources:
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=yaml%2Cbatch
We shouldn't use cat command when defining variables. The command should be located in tasks/steps.
According to your description, I assume you're trying to pass the content of public/7.2 to FILE_VERSION variable. Here's my test:
1.Azure Devops Git repo:
2.Define the VERSION variable:
variables:
VERSION: 7.2
Run the cat command and set job-scoped variable:
- bash: |
FILE_VERSION=$(cat public/$(VERSION))
echo "##vso[task.setvariable variable=FILE_VERSION]$FILE_VERSION"
The whole yaml:
trigger:
- master
pool:
vmImage: 'ubuntu-latest'
variables:
VERSION: 7.2
steps:
- bash: |
FILE_VERSION=$(cat public/$(VERSION))
echo "##vso[task.setvariable variable=FILE_VERSION]$FILE_VERSION"
#Use second bash task to test the variable.
- task: Bash#3
inputs:
targetType: 'inline'
script: |
echo $(FILE_VERSION)
i'm setting up a pipeline for asp.net application. During integration tests task i need to connect to a SQL server. How can i say to the pipeline that i need a sql service ?
I have tried with multiple microsoft hosted agent pool (Windows Server 1803, Hosted 2017 & 2019)
I use Windows Server 1803 and issue is:
The operating system of the container does not match the operating system of the host.
I would like setting up correctly a temporaly sql server to running tests.
I have used localdb instead.
i run this script before my intregration tests task
SqlLocalDB.exe create "DeptLocalDB"
SqlLocalDB.exe share "DeptLocalDB" "DeptSharedLocalDB"
SqlLocalDB.exe start "DeptLocalDB"
SqlLocalDB.exe info "DeptLocalDB"
To connect with powershell: Invoke-Sqlcmd -Query "SELECT GETDATE() AS TimeOfQuery;" -ServerInstance "(localdb)\.\DeptSharedLocalDB"
To connect with sqlcmd: sqlcmd -S (localdb)\.\DeptSharedLocalDB
To connect a c# app (connectionString): "Data Source=(localdb)\.\DeptS
haredLocalDB;Initial Catalog=DeptLocalDB;Integrated Security=True;"
If someone know how to mount a sql server in a container on azure pipeline, it will be appreciated. Thank for reading
Chocolatey is installed on windows-latest.
So, if you in you YAML file define:
pool:
vmImage: windows-latest
you can then install SQL Server Express using choco:
- script: choco install sql-server-express
azure-pipelines.yml:
pool:
vmImage: 'windows-latest'
...
- task: PowerShell#2
displayName: 'start mssqllocaldb'
inputs:
targetType: 'inline'
script: 'sqllocaldb start mssqllocaldb'
After the following connection string is valid:
Data Source=(localdb)\\MSSQLLocalDB;Initial Catalog=my-db;Integrated Security=True;
Source:
https://www.jannikbuschke.de/blog/azure-devops-enable-mssqllocaldb/
In my case (some .NET Core integration tests that needed LocalDB), just using the windows-latest image did the job:
pool:
vmImage: 'windows-latest'
The image comes with Visual Studio which includes LocalDB.
Here a full example of how I achieved running Integration tests using Sql Express in Azure Devops. I had to use the YAML based pipelines so I could use simonauner's approach using Chocolatey to install Sql Express. Make note that I had to install EF Core tools since I use .Net Core 3.1 in this pipeline. Also note that I generate an EF Code First migration SQL file on the fly so that the rigged SQL Express instance is filled with contents.
Deploy SQL Express instance in Azure Devops, install and generate and run EF Code first migration sql script to update database with schema and seed data using EF Code First tools.
# ASP.NET Core (.NET Framework)
# Build and test ASP.NET Core projects targeting the full .NET Framework.
# Add steps that publish symbols, save build artifacts, and more:
# https://learn.microsoft.com/azure/devops/pipelines/languages/dotnet-core
trigger:
- feature/testability
pool:
vmImage: 'windows-latest'
variables:
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
steps:
- script: choco install sql-server-express
- task: NuGetToolInstaller#1
- task: VisualStudioTestPlatformInstaller#1
displayName: 'Visual Studio Test Platform Installer'
inputs:
versionSelector: latestStable
- task: NuGetCommand#2
inputs:
restoreSolution: '$(solution)'
- task: DotNetCoreCLI#2
displayName: Build
inputs:
command: build
projects: '**/*.csproj'
arguments: '--configuration Debug' # Update this to match your need
- script: 'dotnet tool install --global dotnet-ef'
displayName: 'Generate EF Code First Migrations SQL Script Update script'
- script: 'dotnet ef migrations script -i -o %BUILD_ARTIFACTSTAGINGDIRECTORY%\migrate.sql --project .\SomeAcme\SomeAcme.csproj'
displayName: 'Generate EF Code First Migrations migrate.sql'
- script: 'sqlcmd -S .\SQLEXPRESS -Q "CREATE DATABASE [SomeAcmeDb]"'
displayName: 'Create database SomeAcmeDb in Azure Devops SQL EXPRESS'
- script: 'sqlcmd -i %BUILD_ARTIFACTSTAGINGDIRECTORY%\migrate.sql -S .\SQLEXPRESS -d SomeAcmeDb'
displayName: ' Run migrate.sql on SQL EXPRESS in Azure Devops'
# PowerShell
# Run a PowerShell script on Linux, macOS, or Windows
- task: PowerShell#2
inputs:
targetType: 'inline' # Optional. Options: filePath, inline
#filePath: # Required when targetType == FilePath
#arguments: # Optional
script: 'gci -recurse -filter *.dll' # Required when targetType == Inline
#errorActionPreference: 'stop' # Optional. Options: stop, continue, silentlyContinue
#failOnStderr: false # Optional
#ignoreLASTEXITCODE: false # Optional
#pwsh: false # Optional
#workingDirectory: # Optional
- task: VSTest#2
displayName: 'VsTest - testAssemblies'
inputs:
testAssemblyVer2: |
**\*SomeAcme.Tests.dll
!**\*TestAdapter.dll
!**\obj\**
vsTestVersion: toolsInstaller
testFiltercriteria: 'Category=IntegrationTest'
runInParallel: false
codeCoverageEnabled: false
testRunTitle: 'XUnit tests SomeAcme solution integration test starting'
failOnMinTestsNotRun: true
rerunFailedTests: false
I need localdb in order to run database unit tests, and I also require at least SQL Server 2016 SP2 because my team is using some of the newer language features.
On a windows-2019 image, simply use choco or powershell to execute the following command:
choco upgrade sqllocaldb
In the pipelines.yml file, the following is used:
steps:
# Print buildId
- script: |
echo "BuildId = $(buildId)"
When looking at the build log in Azure DevOps, I see just "CmdLine".
Is there a way to give a step or a script a readable name which is visible in the build log?
You just need to add the parameter displayName:
steps:
- script: 'echo "BuildId = $(Build.BuildId)"'
displayName: Test1001
- script: 'echo "BuildId = $(Build.BuildId)"'
displayName: Test1002