When running our Release build (which ultimately labels and versions a changeset), I want the variables to be supplied at queueing time. For example 1.0.23 below:
Is there any way to set these variables as required in order to execute the build?
This new "vNext" build platform is incredibly difficult to Google for.
The best I have come up with thus far is to add a task as the first step in the first phase of the build that checks the required variables are set. If any are not, it fails the build.
I use PowerShell for this:
if ([string]::IsNullOrWhitespace($env:Major)) { throw "Major not set" }
This is not ideal, as the build still has to wait to get scheduled on an agent, sync sources, &c. before the validation code runs and fails the build. But, it's still better than building everything just to have, say, packaging (step 14/15) fail because the version wasn't set.
I've opened a feature request on the VSTS UserVoice page asking for "required queue variables".
Related
Following this Microsoft tutorial (Run unit tests with your builds), I was expecting to be able to run my unit-tests automatically when a build is triggered, such as a Pull request.
However, when I look in the Pipeline / Builds tab and try to edit my pipeline, there is nothing that allows me to add a new task (see screenshot below).
However, there doesn't appear to be any way of adding a task. I can't even switch to the YMAL without navigating to the source via the Repo. I was hoping to use the GUI though as my YMAL is non-existent.
I have created a test solution with the following structure, which is held in the repo:
Core Solution
|_ Class Library Project (.NET Core)
|_ MSTest Test Project (.NET Core)
I was hoping to have a build step followed by a Unit Test step using the tests in my MSTest Test Project (.NET Core) project once they were built.
There appears to be a Tasks option in the Releases tab by the way, but I was expecting to be able to add tasks for builds as well, especially Unit Tests.
Being new at this, perhaps I have missed or misunderstood something. I would be grateful for any help and to be pointed in the right direction.
It seems that there is an obscure link that takes you through to the correct process, found it quite by accident, see screenshot below:
It turns out that there is a little link titled Use the visual designer that I'd missed. Seems a little odd that most of the tutorials discuss this process and yet it's partially obscured. I guess that this shows that the platform is a work in process and still being added to and improved.
Another few caveats for those descending this little rabbit hole, after selecting the Use the visual designer link, be sure to select the Empty pipeline template, or whatever is appropriate to your project/solution type, and not the YAML option at the top of the list, otherwise you'll be back where you started.
Finally, it seems that automated Unit Tests don't work on Agents other than Hosted VS2017 Agents (that said, I haven't tried the Hosted option). This is set in the very next screen by selecting the Pipeline and selecting the Agent pool from the drop-down.
One last thing... The pipeline won't run automatically unless you check the Enable continuous integration checkbox on the Triggers tab.
Once this is all done, I simply chose the tasks needed for the build by clicking the plus symbol on the Agent job 1 item.
Good luck
Kaine
You have created a new YAML style of build configuration. Currently Azure DevOps does not support of having YAML & GUI editor at the same time (this is upcoming feature in Q1/2019).
To get a GUI editor, create new build pipeline.
In this selection click "Use the visual designer".
Then at template phase, don't select YAML. Any other template will do. You can easily delete all the build steps after selecting template, so don't be afraid to choose any.
I'm changing the build number of the TeamCity (9.1.4) build with service messages (Build Script Interaction) like this in Powershell:
Write-Host "##teamcity[buildNumber '$version.$arg2']"
This is working absolutely fine.
The problem is that the AssemblyInfoPatcher doesn't want to use this updated build number.
So I tried to use a variable/parameter for it but this also doesn't work.
I defined the following variable "Major.Minor.Patch" as a "Configuration Parameter" or as an "Environment Variables". The AssemblyInfoPatcher is using these variables just fine and changes the file version of my files with the version defined in TeamCity in the build.
If I try to change the variable/parameter with a service message it doesn't work. The AssemblyInfoPatcher is still using the old value.
Example with environment variable
Write-Host "##teamcity[setParameter name='env.Major.Minor.Patch' value='$version']"
Example with configuration parameter
Write-Host "##teamcity[setParameter name='Major.Minor.Patch' value='$version']"
Am I doing something wrong or is it just not possible? The only thing I want is that my files have the same version number as my TeamCity build...
The AsssemblyInfoPatcher runs before any of the build steps (and then runs again to revert your AssemblyInfo files after all your build steps). Thus, if one of your build steps sets Major.Minor.Patch using a service message, it's really too late to the game.
Maybe you could string multiple build configs together. The first config (A) would set up the parameter like you're doing now, and then trigger the second config (B), which would use the AssemblyInfoPatcher. B would have a snapshot dependency on A (in addition to the finish-build trigger) and thus its AssemblyInfoPatcher would be able to refer to %dep.A.Major.Minor.Patch%. This parameter, of course, would already be available when B's AssemblyInfoPatcher runs.
Currently, when I run an application process that installs various components, if I don't specify a version for any of them, the deploy component process doesn't run, and it says "No Version Selected". However, the step doesn't fail, and the process continues. Is there a way to configure the process to fail if not all components have a version? Or is there a way for me to interrogate the manifest for the process in a step at the top to figure it out myself and fail accordingly? I currently can find no way to do either of these things. The version of UCD I am using is 6.1.1.3.
If your component process is configured as "Process Type* Operational (With Version)" then if you don't select the version the job will fail.
Please note, although my specific example here involves Java/Grails, it really applies to any type of task available in Bamboo.
I have a task that is a part of a Bamboo build where I run a Java/Grails app like so:
grails run-app -Dgrails.env=<ENV>
Where "<ENV>" can be one of several values (dev, prod, staging, etc.). It would be nice to "parameterize" the plan so that, sometimes, it runs like so:
grails run-app -Dgrails.env=dev
And other times, it runs like so:
grails run-app -Dgrails.env=staging
etc. Is this possible, if so, how? And does the REST API allow me to specify parameter info so I can kick off different-parameterized builds using cURL or wget?
This seems to be a work around but I believe it can help resolve your issue. Atlassian has a free plugin call Bamboo Inject Variables Plugin. Basically, with this plugin, you can create an "Inject Bamboo Variables from file" task to read a variable from a file.
So the idea here is to have your script set the variable to a specific file then kick off the build; the build itself will read that variable from the file and use it in the grails task.
UPDATE
After a search, I found that you can use REST API to change plan variables (NOT global). This would make your task simpler: just define a plan variable (in Plan Configuration -> tab Variables) then change it every time you need to. The information on how to change is available at Bamboo Knowledge Base
In our msbuild script we can run unit tests without using the vsmdi file:
We would like to enforce tests to be run on check in. The "Testing policy" seems to require a .vsmdi file. Is there a way to do this without one?
The out-of-the-box testing policy simply checks for the presence of a TestResults folder that has been created since the last checkin, indicating that MSTest has been run. If it finds one it then scans the test results for a reference to the .vsmdi file that is mentioned.
You could write a custom policy that does much the same thing but instead of looking for a .vsmdi file in the test results look for something else as an indicator that tests you want run have actually been run (and that they pass).