I am new to Gradle, so bear with me.. I am simply trying to call a .ps1 file to execute with gradle. How would I go about setting up a build.gradle file to execute the .ps1 file within the same directory? Thanks in advance!
You can use gradle Exec
Example:
task execPs(type:Exec) {
commandLine 'cmd', '/c', 'Powershell -File sample.ps1'
}
// add this task to your build.gradle file and execute gradle execPs
// You can use a different name for this task
// You can add a dependency to include this task as part of your normal build. (like below)
// build.finalizedBy(execPs)
// with the above command gradle build will call your task at the end of build
Related
I need help. I am trying to configure roslyn code analyser in azure devops. I need the MsCommandLine to add this roslyn analyser.
and the build task generated is
- task: RoslynAnalyzers#3 inputs:
userProvideBuildInfo: 'msBuildInfo'
msBuildVersion: '16.0'
msBuildArchitecture: 'amd64'
msBuildCommandline: '$(Parameters.solution)'
But i am getting error
MSBUILD : error MSB1003: Specify a project or solution file. The
current working directory does not contain a project or solution
file.
What should be added in MSBuildCommandLine to specify source directory of the project?
I have referred to https://secdevtools.azurewebsites.net/helpRoslynAnalyzers.html
and https://www.1eswiki.com/wiki/Secure_Development_Tools_Extension_For_Azure_DevOps .
I am not getting any clue about this MSCommandLine. How to specify it?
The commandline should begin with a full path to MSBuild.exe.
The command will run with $(Build.SourcesDirectory) as the working directory. You may specify the full path to MSBuild.exe, and try again.
The commandline should begin with a full path to MSBuild.exe or dotnet.exe. So your msBuildCommandline statement should look like below
msBuildCommandline: "C:\Program Files\dotnet\dotnet.exe" build '$(Parameters.solution)' ...
I'm trying to set up a CI deployment for my NuGet package on VSTS so that when a new commit is made, a package is packed and sent to my feed. Unfortunately I'm not sure where to start; most of my experience with versioning has been manually updating a file that sits within the solution, hence this question, so if there is a better way to do this let me know.
I would like the name to be the version number in the AssemblyInfo.cs file ("0.0.1") with the build number of the automated build appended. So the final result would look something like "0.0.1.35".I would like to also avoid using date/time in my naming; a lot of the suggestions are to use this but I really wish to keep the version number clean so that I can release the packages.
I'm using the 'NuGet pack' task so I only have the options 'Use date-time', 'Use environment variable' or 'Use the build number'.
Date/time means I have to manually input a major, minor and patch which I would prefer to be automatic.
Environment variable, sounds like this could be it but I think I'm missing what I should put in this field.
I set my build name to be "$(BuildDefinitionName)_$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r)"but not getting the result I hoped.
Any help would be greatly appreciated!
Do you have the desire to have the file version match the NuGet package version? If so, you can use the following solution.
By default, the NuGet pack command will use the file version as the Package Version. To use this functionality to get the expected output that you want, you will need to update the file version during the build. This can be done easily with the Update Assembly Info task from the VSTS marketplace. There are a number of other similar tasks, but this one allows you to only modify the revision part of the file version independently of the Major, Minor, and Build versions.
Add the Update Assembly Info task to your VSTS account
Modify your build definition and add the 'Update Assembly Info' task to the build. Ensure that it is before your Visual Studio Build or MSBuild Task as you need to change the assembly info before the build occurs
Set the values in the Update Assembly Task to match what you need for your assemblies. By default it sets Revision to $(Build.BuildId) which is what you want based on your requirements
Turn 'Automatic Package Versioning' off in the Nuget Pack task
Add the 'Update Assembly Info' task to you build process and ensure that it is before your Visual Studio or MSBuild task.
Your build should now create a Nugetpackage of 0.0.1.{Build.BuildId}
Note: this was tested with version 2.* of the NuGet Task and Version 2.* of Update Assembly info task.
The simple workflow is using environment variable:
Add new variable to build definition (e.g. packageVersion)
Add PowerShell task to get version in AssemblyInfo.cs (you can refer to the code in Use a PowerShell script to customize your build process)
Update variable value in PowerShell script (step 2) by calling Write-Host "##vso[task.setvariable variable= packageVersion;]xxx" (Logging Commands)
Add NuGet pack task (Automatic package versioning: Use an environment variable; Environment variable:packageVersion)
I wrote this PowerShell script to do that:
param
(
[parameter()][string] $FolderPath,
[parameter()][string] $FileExtension
)
$RegularExpression = [regex] 'AssemblyInformationalVersionAttribute\(\"(.*)\"\)'
$path = Get-Location
# Get the files from folder that ends in $FileExtension content
$assemblyInfoFile = (Get-ChildItem -Path $FolderPath -Force -Recurse -File -Include *$FileExtension).Name
# Get the Content of the file and store it in the variable
$fileContent = Get-Content $FolderPath/$assemblyInfoFile
foreach($content in $fileContent)
{
$match = [System.Text.RegularExpressions.Regex]::Match($content, $RegularExpression)
if($match.Success) {
$version = $match.groups[1].value
}
}
# Check if variable has content
if ($version)
{
Write-Host $version
Write-Host ##vso[task.setvariable variable=packageversion]$version
}
To run the script locally:
.\powershellScriptName.ps1 -FolderPath "c:\Git\" -FileExtension "AssemblyInfo.cs"
FolderPath: the path to output build solution
FileExtension: part of the name where we gonna search the version
VSTS steps:
Build a task to build the solution and save de output directory in a variable;
Add PowerShell task to call your script with FolderPath and FileExtension as parameters;
In the end, packageversion should have the correct version
** Project technology: .netcore
How can I specify which spec file to run in protractor using command line arguments without using grunt or any task runner?
Use the --specs command-line argument:
protractor protractor.conf.js --specs='specs/run-just-this-spec.js'
When the gradle application plugin generates the startScripts, it generates for both windows and linux. Is there a way to exclude the windows script from going to bin/ when running distZip task?
It's possible to delete windows script in the doLast block of the startScrips task, as:
startScripts {
doLast {
delete windowsScript
}
}
You can use startScripts.enabled = false in your build.gradle file. Tested with gradle 3.4
One possible solution is to define an exclude spec for the distZip task in build.gradle as follows:
distZip.exclude "**/*.bat"
This will exclude all .bat files from the zip distribution.
I have a gradle plugin that uses the project.version variable.
How ever, the version in the plugin does not update when I change the version in the build.gradle file.
To illustrate:
plugin
// my-plugin
void apply(Project project) {
project.tasks.create(name: 'printVersionFromPlugin') {
println project.version
}
}
build.gradle
version '1.0.1' // used to be 1.0.0
task printVersion {
println project.version
}
apply plugin: 'my-plugin'
Result
> gradle printVersion
1.0.1
> gradle printVersionFromPlugin
1.0.0
You can use gradle properties to extract project version without adding a dedicated task to the build.gradle file.
For example:
gradle properties -q | grep "version:" | awk '{print $2}'
Both the build script and the plugin make the same mistake. They print the version as part of configuring the task, rather than giving the task a behavior (task action). If the plugin is applied before the version is set in the build script (which is normally the case), it will print the previous value of the version property (perhaps one is set in gradle.properties).
Correct task declaration:
task printVersion {
// any code that goes here is part of configuring the task
// this code will always get run, even if the task is not executed
doLast { // add a task action
// any code that goes here is part of executing the task
// this code will only get run if and when the task gets executed
println project.version
}
}
Same for the plugin's task.