After some time, I went to a project to redo a build and the command I give results in:
qbs build -p archive config:release modules.cpp.useRPaths:false
Restoring build graph from disk
ERROR: Property values set on the command line differ from the ones used for the previous build. Use the 'resolve' command if you really want to rebuild with the new properties.
Is there any way to determine which properties were set in the previous build?
No, the command-line frontend does not expose this functionality. But independent of that, it would be helpful if the error message listed the differing properties. You might want to create a task for that at bugreports.qt.io.
Related
I am adding a PowerShell script to run in my build to get the Version Number for the build. When I use the builder(Box with ...) to get the file, it takes me to my TFS Project and I work my way down to the file. When the build definition runs it fails at that step, because it cant find my script.
What it has done is prepended the local Servers work directory to the front of the Path it had me choose.
I feel this is a Bug or how am I suppose to get the most current copy of a script in TFS when the Build Definition runs.
Tried with a simple powershell script on my side, but couldn't reproduce your issue, the script is working.
Only add one step in build, and map to $/teamproject in Repositity, then select the script:
To narrow down the issue, you could create a new pipeline with only one task-Powershell, check what will happen.
If you still get error, please share detail logs with system.debug=true enable.
Also take a look at this tutorial about how to use powershell fetch/change build number, which may helps-- Use a PowerShell script to customize your build pipeline
Update
According to your error info, you are lacking of the definition.
Please make sure you have specified the value in options--build number format
$(BuildDefinitionName)_$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r)
Then it should run without any problem:
In Azure DevOps I have a Pipeline variable "package version" and I set it using 0.1.3$(Rev:.r)-alpha .
I use that variable to replace the "Version" in the .net core project file.
In the Build tasks the dotnet build give me this error:
so I assume the Pipeline variable cannot use a nested variable.
There is a nother way or a different syntax to do it?
[Edit]
The nested variables should work.
I think the error was the dotnet pack using Automatic package versioning set to "Use the build number" that contain the wrong $(rev:.r) (lowercase!).
Using a custom string for Version in the VS project file gives noise on VS (error if the file is open, warning otherwise) and now the Pipeline Build give me an error on dotnet nuget restore because of the invalid Version.
I decided to use a simple clean version, <Version>0.1.2</Version>, that I can choose and document.
Then I want to find a way to read it in the build pipeline and create a custom variable attaching the Build Revision:
0.1.2$(Rev:.r) => 0.1.2.123
That is the result I want.
I found this: https://marketplace.visualstudio.com/items?itemName=tmarkovski.projectversionasvariable
I'm using it with the default settings.
I'm using the variables it creates to compose a new variable, "package version":
and I use that in the nuget pack task:
but it does not work.
The resulting variable still contain "$(Rev:.r)" not parsed.
I'll try to use again the "Automatic package versioning" and create the build number in the Options...
[Edit 2]
Set the build version number in the Pipeline Build Options worked.
It's not the optimal solution because the Build Number is not parsed and looks awful.
[Solution]
$(Rev:.r) is not available outside Build / Options.
I used $(Build.BuildNumber) and I'm able to create a composed variable:
$(Version.MajorMinor).$(Build.BuildNumber)-alpha
Build.BuildNumber is valorized in Build/Options: $(Build.DefinitionVersion)$(Rev:.r)
Version.MajorMinor is created by the Project Version As Build Variable add-on.
I don't know how to obtain the same result without using a third party component.
I'm glad my extension helped and thanks for the nice review. If you want more control and have a little time to spend to play with PowerShell, you can easily achieve what you want in two steps, without using third party extensions.
Read and parse the .csproj file as XML
Set build variables
Here are couple of links on reading XML files and working with build variables, it's actually pretty easy.
https://www.business.com/articles/powershell-read-xml-files/
VSTS: Pass build/release variables into Powershell script task
[xml]$XmlDocument = Get-Content -Path $env:project_file
echo $XmlDocument.Project.PropertyGroup.Version
https://learn.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=vsts&tabs=yaml%2Cbatch
Write-Host '##vso[task.setvariable variable=package_version;issecret=true]0.1.2.'
Note: my answer wouldn't fit in a comment, I had to post an answer.
OK, so we're stuck on on-site TFS2015 at the moment. My Nuget Publisher build step is failing with:
##[error]Ambiguous option 's'. Possible values: Source SymbolSource SymbolApiKey.
It appears inside the build step they have put -s instead of -source, and in later versions they've added more commands starting with s. So what are my options?
Write my own in Powershell (Can do, but TFS Build is very clunky for this)
Find wherever this is defined in TFS (hopefully a template .ps file) and fix it there (Anyone know where this is kept?)
Upgrade to a later version of TFS (a fairly large, but perhaps inevitable undertaking)
Somehow override the -s command another way?
????????
Invoke NuGet.exe however you'd like via the Command Line task
If you did #3 (upgrade TFS), you'd find that the PowerShell build task can run an in-line PowerShell script, making it significantly less clunky.
You may be able to extract and modify the task with the tfx command line utility, but I can almost guarantee this will have nasty ramifications when you do eventually upgrade.
I'm adding my answer for details about step 5 maybe it will help team that are still using TFS 2015.
Nuget Publisher seems to use old version, which means "-s" option will not work.
To bypass this situation you can setup your build as follow:
1- Add Nuget Packager Step and specify the the Package Folder value:
2- Add a new step which would copy your artifacts(Note that contents that should be copied must end with nupkg):
3- And Finaly you can just run a command line that will perform the publish operation. In my case we are pushing the whole repository using init command(PackageRepository is the path to our internal feed that we set in we've set in Variables section):
I would like to make my main branch TFS build definitions to treat warnings as errors so that the build fails when the projects are not error free. Since I do not want to activate "treat error as warning" in all project as a default, my first idea was to add a powershell script to my main build definition that substitues false with true in the line <TreatWarningsAsErrors>...</TreatWarningsAsErrors> in all csproj files it finds (something along the line of this). Is there any better/straighter way via some option as part of the build definition settings?
In the build definition specify /p:TreatWarningsAsErrors=True in the MSBuild argument field.
This will override any setting from the csproj files.
Unfortunately, there is no this kind of settings as part of the build definition.
However, you could be able to return warnings and errors from your powershell script using logging commands. With using task.logissue type=error you could fail the build task and then fail the build.
More details you could take a look at this similar question: Is it possible to raise and display build warnings from build steps using TFS 2015
I had set up fxcop Custom Dictionaries for several projects in Visual Studio. However when it comes to running FxCop as part of our build process (using NAnt), we ran into trouble.
We currently have FxCop set up to run with the command line arguments /project:ProjectPath as well as /file:OutputPath/*.dll, and it seems to be respecting those arguments.
How can I tell FxCop to respect what I've set up in my .csproj files; through either the command line, or in a .fxcop project file?
Ideally, we don't want to have to change anything any time we add a new project or a new CustomDictionary.xml file. Hopefully, it would find all the custom dictionaries by itself.
The task that executes FxCopCmd in MSBuild actually fetches the codeanalysisdictionary.xml file location from the .csproj. So if you want to execute fxcop yourself, you'd either have to run it through MSBuild or duplicate the behavior into your nant task.