I'm just starting some experiments to replace our TeamCity builds with Azure DevOps Pipelines. One of my projects has a Grunt dependency, so I have created a task:
- task: Grunt#0
displayName: 'Run Grunt task bower install'
inputs:
workingDirectory: $(webDir)
targets: bower:install
I've read the documentation for the grunt task, and it says that I can provide a working directory, but everything I've done so far only yields an error message with no particularly helpful feedback:
## [error] Not found gruntfile: D:\a\1\s\gruntfile.js
Here's a few of the workingDirectory inputs I've tried:
workingDirectory: 'Web'
workingDirectory: '.\\Web'
workingDirectory: '$(Build.SourcesDirectory)\\Web'
workingDirectory: $(Build.SourcesDirectory)\Web
Ultimately, I'm expecting that putting a string in the workingDirectory will have some impact, but I'm obviously doing something wrong, and can't seem to see what it is.
One last thing, I created a few new tasks to run before this grunt task, just to see what the CWD is, and to validate my knowledge of workingDirectory for other tasks.
- script: cwd
displayName: show working dir1
workingDirectory: '$(Build.SourcesDirectory)\\Web Store'
- script: cwd
displayName: show working dir2
workingDirectory: $(Build.SourcesDirectory)\Web Store
- script: cwd
displayName: show working dir3
workingDirectory: $(webStoreDir)
- task: CmdLine#2
displayName: show working dir4
inputs:
workingDirectory: $(webStoreDir)
script : cwd
In all 4 cases, working directory is passed to the Cmd.exe ...
Evidently the "grunt" task operates under some different concepts, but I'm at a loss to work them out.
How can I get the grunt task to accept the working directory?
Related
I've a git repository on our Azure Devop. I publish the application on firebase everytime it is published on master.
Here is my current YML:
trigger:
- master
pool: vmImage: ubuntu-latest
steps:
- task: NodeTool#0 inputs:
versionSpec: '14.x' displayName: 'Install Node.js'
- task: CmdLine#2 inputs:
script: 'npm install -g firebase-tools'
workingDirectory: '$(Agent.ToolsDirectory)' displayName: 'install firebase tools'
- script: |
npm install
npm run build displayName: 'npm install and build'
- script: |
cd functions
npm install displayName: 'install functions dependencies'
- task: CmdLine#2 inputs:
script: 'firebase deploy --token "$(FIREBASE_TOKEN)" -m "$(Build.BuildNumber)"' displayName: 'firebase publish -m "$(Build.BuildNumber)"'
I recently noticed the following warning in my jobs:
! Authenticating with a login:ci token is deprecated and will be
removed in a future major version of firebase-tools. Instead, use a
service account key with GOOGLE_APPLICATION_CREDENTIALS:
https://cloud.google.com/docs/authentication/getting-started
The article is not quite clear, it talks more about how to access stuff within code, not directly with firebase deploy. After some search I was able to find multiple example with a JSON file.
But in my case, with a git repository and a pipeline, I'm not sure how to proceed:
I don't want to store in the git repository a file with the credentials, it has to be some kind of secret stored in azure devop.
Azure Devop doesn't allow me to store file, only string
So, if I've generated this json, how can I use it? Or is there another method?
I have the following task:
- task: DotNetCoreCLI#2
inputs:
command: 'build'
projects: 'XXX'
arguments: '-c "Release" /p:Platform="x64"'
and I want to set the outputpath of the build so that I can publish an artifact after compiling.
/p:OutputPath="$(build.artifactStagingDirectory)\XXX"
But when I specify the output directory (--output $(Build.ArtifactStagingDirectory)\X') I get an error MSB3073
If I remove the output argument it works.
How can I build correctly so that I can publish the artifact or solve the output issue?
If you don't specify the output directory when compiling, the project will compile and place the bin folder in the subfolder of the project. This is the same behavior if you were to compile the solution locally. So you could publish the artifact from that folder:
- publish: '$(Build.SourcesDirectory)\path-to-my-project\bin\'
artifact: myArtifact
For .NET core projects, the command syntax for dotnet build is:
dotnet build [options] <project | solution>
The syntax for the output directory is -o <directory> or --output <directory>. The important detail here is you need to wrap the output directory in quotes and additional msbuild parameters are specified as -p:<param>="value"
Fun tip, you can use the > operator in YAML to represent multi-line strings, so you could represent your task this way:
- task: DotNetCoreCLI#2
inputs:
command: 'build'
projects: 'XXX'
arguments: >
-c "Release"
-p:Platform="x64"
-o "$(Build.artifactStagingDirectory)\XXX"
Also note, this being .NET Core, if you're using a Linux build agent, you'll need to use backslashes ('/') for the file path.
Have you tried adding it to the arguments?
- task: DotNetCoreCLI#2
inputs:
command: 'build'
projects: 'XXX'
arguments: '-c "Release" /p:Platform="x64" /p:OutputPath="$(build.artifactStagingDirectory)\XXX"'
Problem Background:
I have a class library project that contains the database migrations (MyProject.MigrationProject.csproj). And in startup.cs of the entry project (Web API), I have explicitly included migration assembly like following.
services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(
configuration.GetConnectionString("DefaultConnection"),
x => x.MigrationsAssembly("MyProject.MigrationProject")));
Then I run the dotnet ef migration command locally using powershell. The command I'm using is:
dotnet ef migrations script --no-build -o D:\migrations\script.sql --idempotent --project D:\...\src\MyProject.MigrationProject\MyProject.MigrationProject.csproj --startup-project D:\...\src\MyProject.WebApi\MyProject.WebApi.csproj
The above command executes successfully on my machine and creates the desired script.sql file on output location. The same command is then used in the build pipeline (using command line task) in Azure Devops but for some reason it fails there. The command on Devops looks like this:
dotnet ef migrations script --no-build -o $(Build.ArtifactStagingDirectory)\migrations\script.sql --idempotent --project $(Build.SourcesDirectory)\src\MyProject.MigrationProject\MyProject.MigrationProject.csproj --startup-project $(Build.SourcesDirectory)\src\MyProject.WebApi\MyProject.WebApi.csproj
The Error I get from Devops:
Script contents:
dotnet ef migrations script --no-build -o D:\a\1\a\migrations\script.sql --idempotent --project D:\a\1\s\src\MyProject.MigrationProject\MyProject.MigrationProject.csproj --startup-project D:\a\1\s\src\MyProject.WebApi\MyProject.WebApi.csproj
##[debug]AGENT_VERSION: '2.193.1'
##[debug]AGENT_TEMPDIRECTORY: 'D:\a\_temp'
##[debug]Asserting container path exists: 'D:\a\_temp'
##[debug]Asserting leaf path exists: 'C:\Windows\system32\cmd.exe'
========================== Starting Command Output ===========================
##[debug]Entering Invoke-VstsTool.
##[debug] Arguments: '/D /E:ON /V:OFF /S /C "CALL "D:\a\_temp\37fc4a71-a144-4332-9a84-04e6138a2538.cmd""'
##[debug] FileName: 'C:\Windows\system32\cmd.exe'
##[debug] WorkingDirectory: 'D:\a\1\s'
"C:\Windows\system32\cmd.exe" /D /E:ON /V:OFF /S /C "CALL "D:\a\_temp\37fc4a71-a144-4332-9a84-04e6138a2538.cmd""
An error occurred while accessing the Microsoft.Extensions.Hosting services. Continuing without the applicgation service provider. Error: A certificate with the thumbprint 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' could not be found.
Unable to create an object of type 'ApplicationDbContext'. For the different patterns supported at design time, see https://go.microsoft.com/fwlink/?linkid=851728
##[debug]Exit code: 1
##[debug]Leaving Invoke-VstsTool.
##[error]Cmd.exe exited with code '1'.
##[debug]Processed: ##vso[task.logissue type=error]Cmd.exe exited with code '1'.
##[debug]Processed: ##vso[task.complete result=Failed]Error detected
##[debug]Leaving D:\a\_tasks\CmdLine_d9bafed4-0b18-4f58-968d-86655b4d2ce9\2.182.0\cmdline.ps1.
Finishing: CmdLine
At times, by tweaking the YAML file, I was able to get rid of the first error but the 2nd one never disappeared on devops. The issue is pretty much because of having separate project for Migrations but I think that's how it should be...
My Build pipline's YAML:
trigger:
- develop
pool:
vmImage: 'windows-latest'
variables:
solution: '**/*.sln'
buildPlatform: 'Any CPU'
buildConfiguration: 'Release'
steps:
- task: DotNetCoreCLI#2
displayName: Restore
inputs:
command: restore
projects: '**/MyProject.WebApi.csproj'
- task: DotNetCoreCLI#2
displayName: Build
inputs:
projects: '**/MyProject.WebApi.csproj'
arguments: '--no-restore'
- task: DotNetCoreCLI#2
displayName: Test
inputs:
command: test
projects: '**/*[Tt]ests/*.csproj'
arguments: '--no-restore --no-build'
- task: DotNetCoreCLI#2
displayName: 'Publish WebApi'
inputs:
command: publish
publishWebProjects: false
projects: '**/MyProject.WebApi.csproj'
arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory) --runtime -r $(runtime)'
- task: CopyFiles#2
inputs:
Contents: '**'
TargetFolder: '$(Build.ArtifactStagingDirectory)'
- task: UseDotNet#2
inputs:
packageType: 'sdk'
version: '5.x'
- task: DotNetCoreCLI#2
displayName: Install dotnet-ef
inputs:
command: 'custom'
custom: 'tool'
arguments: 'install --global dotnet-ef --version 5.0.10 --ignore-failed-sources'
- task: CmdLine#2
inputs:
script: dotnet ef migrations script --no-build -o $(Build.ArtifactStagingDirectory)\migrations\script.sql --idempotent --project $(Build.SourcesDirectory)\src\MyProject.MigrationProject\MyProject.MigrationProject.csproj --startup-project $(Build.SourcesDirectory)\src\MyProject.WebApi\MyProject.WebApi.csproj
- task: PublishBuildArtifacts#1
displayName: 'Publish Artifact: drop'
My Suspicion:
It could be an issue with the directory where the command is executed from (on ADO powershell). I suspect this because, on my local machine, before calling the method x.MigrationsAssembly("MyProject.MigrationProject"), the following command failed when I executed it from a directory other than the entry project's directory but when I navigated the powershell to entry project and executed the same command, it went successful. The command at that time was:
dotnet ef migrations script -o D:\migrations\script.sql --idempotent --project D:\...\src\MyProject.MigrationProject\MyProject.MigrationProject.csproj
I'm already using the same YAML in another project but that contains everything in single Web API project and so, I do not get any issue there.
Question:
What am I doing wrong here? What can I do to fix this issue? Any help would be appreciated.
Project Details
DotNet 5.0
EntityFramewokCore 5.0.10
Visual Studio 2019
If I'm missing anything, please ask.
Updates:
My suspicion about working directory for executing the dotnet ef command appears to be wrong as I tried that by supplying workingDirectory parameter to the command line tasks. It works on local machine though.
Thanks #jane-ma-msft
The Error message shows that it is a Certificate error. Please follow the work around to fix the issue.
Try to generate a new certificate or cancel certificate validation.
Check your .sln file. If it has PackageCertificateKeyFile & PackageCertificateThumbprint please try to remove the properties and restart a pipeline.
Or Check that it is configured correctly and that you have uploaded the correct certificate file to the appropriate path.
Make sure that the agent windows-latest has all the .NET SDK versions you need and all the software your project needs to reference. If not, use the task or command line to download them. Click this link to view the software installed on the windows-latest agent.
If you are using the Microsoft-hosted Windows agents in your pipeline, please try to use the self-hosted Agent in your pipeline. Click this document for detailed steps.
Refer here Link 1 & Link 2
I have AzureDevops pipeline to build and test my .net core Azure Functions solutions. Locally tests are working fine but they do fail on build Agent(I tried different agents)
Here is error log:
##[error]Error: The process 'C:\Program Files\dotnet\dotnet.exe' failed with exit code 1
##[error]Dotnet command failed with non-zero exit code on the following projects : C:\BuildAgent\_work\20\s\UnitTestProject\UnitTestProject.csproj
##[section]Finishing: Test
Error:
Here is my yaml file:
trigger:
- dev
pool: 'SelfHosted'
variables:
workingDirectory: '$(System.DefaultWorkingDirectory)/'
steps:
- task: DotNetCoreCLI#2
displayName: Restore
inputs:
command: 'restore'
projects: '**/*.csproj'
feedsToUse: 'select'
- task: DotNetCoreCLI#2
displayName: Build
inputs:
command: 'build'
projects: '**/*.csproj'
arguments: '--output $(System.DefaultWorkingDirectory)/publish_output --configuration Release'
- task: DotNetCoreCLI#2
displayName: Test
inputs:
command: 'test'
projects: '**/*.csproj'
publishTestResults: false
Please suggest, thanks in advance!
When investigating above cs0579 duplicate AssemblyInfo error. It is probably because the test process provides assembly information separately and another AssemblyInfo.cs file get generated, which caused the duplication.
You can try below to make sure these assembly information is declared only once in your project.
1, Removing the AssemblyInfo.cs file from your project to prevent the duplication conflict.
2, you can try adding below lines to your .csproj files
<PropertyGroup>
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
</PropertyGroup>
Please check this similar thread for more possible fixes
I faced similar issue with my automation code's Build pipeline with CI. I was using ".Net Core" task for test execution.
Solution:
I switched my "test" execution task from .Net Core to "Visual Studio test".
In VSTest task under "Test files" i specified exact project name which contains Test Cases. Instead of main solution.dll. As shown in image.
I am getting started with azure-pipelines.yml
I wanted to have 2 jobs within the same stage. One to build a solution and the other to run unit tests.
The problem is that the second job executed a script step and it does not find a folder Release that the previous one should have created:
trigger:
- master
pool:
vmImage: 'ubuntu-18.04'
stages:
- stage: CI
jobs:
- job: Build
steps:
- task: NuGetAuthenticate#0
- script: dotnet restore --no-cache --force
- script: dotnet build --configuration Release --no-restore
- job: UnitTests
dependsOn: Build
steps:
- script: dotnet vstest test/*UnitTests/bin/Release/**/*UnitTests.dll
However if I add all the steps within the same job it works:
trigger:
- master
pool:
vmImage: 'ubuntu-18.04'
stages:
- stage: CI
jobs:
- job: Build
steps:
- task: NuGetAuthenticate#0
- script: dotnet restore --no-cache --force
- script: dotnet build --configuration Release --no-restore
- script: dotnet vstest test/*UnitTests/bin/Release/**/*UnitTests.dll
I cannot find an answer on why a dependent job cannot find on the file system the folders that a previous one has generated. Any explanation or link to something that clarifies that would be much appreciated.
I have used gitlab in the past and I don't recall a similar behavior although I don't know whether it had the concept of job as a different thing to steps.
The key element that you are missing is that jobs run on independent agents (separate computers) and do not have any kind of shared filesystem.
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/phases?view=azure-devops&tabs=yaml
Any files created in one job that you want to make available on a dependent job must be explicitly staged (in job 'A') and then explicitly downloaded (in job 'B').
See publish:
https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/publish-build-artifacts?view=azure-devops
And download:
https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/download-build-artifacts?view=azure-devops