I built a custom build processes template based on the DefaultTemplate.xaml and added a few parameters. They show up fine on the Build definition window but I can not find a way to have them be displayed on the parameters tab of the Queue New Build Dialog.
I am hoping that this is possible, I would rather not need to define a separate build for each variation of parameters.
You can define that in the Metadata parameter: http://www.ewaldhofman.nl/post/2010/05/17/Customize-Team-Build-2010-e28093-Part-6-Use-custom-type-for-an-argument.aspx
You can play with the "View the parameter when" option at the bottom
Related
I have created a custom workflow where tickets or issues are submitted then the order of workflow steps is:
review (ALL)
business justificatioN
in progress
verification (ALL)
deployment
testing
done
ON HOLD (ALL)
RETIRED (ALL)
I created the custom workflow by making a copy of the default workflow with TODO IN PROGRESS, and DONE Status however when you go to edit an issue in my custom workflow you still have the option to change the status to TO DO (from the default workflow) even though my custom workflow is clearly the one which is selected for the Scrum project.
What do I need to modify so that the TO DO STATUS from the default workflow isn't showing up at the top of my issues.
For example if an issue is created using the custom workflow the STATUS defaults to REVIEW as expected as it is the first step in the workflow. When trying to transition it to the business justification step while viewing the issue a STATUS of TO DO is visible.
How can I remove the option to change the status to TODO given it is not part of my custom workflow which is applied to the project and is instead part of the default workflow.
Can I remove the default workflow for the project? to achieve this (I am not sure how to completely remove the default workflow) so far I have only been able to assign my own.
This is possible if either:
The TODO status is still used in your custom workflow.
You're looking at an issue that does not use your workflow. This is possible if your "Workflow Scheme" is not configured correctly. A project has a "workflow scheme" that can contain multiple "workflows" for different "issue types". You can review these settings in your project's settings. The documentation is available here.
Currently I have few custom activities in the main build template. Each additional activity is stored in same binary but different class. To update binary I need to delete old one, check-in delete, copy manually from bin folder to tfs build controller folder, add items to source control and check in changes.
I would like to prevent problem of missing custom activities binary from build template while doing this process.
Can I do it any other way. So there is no time when binary doesn't exist in source control.
You can easily check in the new DLL over the top of the previous one.
If you are using a local Workspace then you just drop the new DLL on top of the old one. This can be automated with a post build script.
If you are using a server workspace (and files are read only) then you will need to check out the file before copying the new one over the top.
You can have an automated build that automated this entire process.
Usually, you should have two projects in your solution. One of the projects is for the custom code and custom activities, the other one to modify the build process template.
After you modify the process template, you need to check in process template and custom activities. The custom activities path should have been specified in your build controller.
Check this blog on how to create your own activity: http://www.ewaldhofman.nl/post/2010/04/29/customize-team-build-2010-e28093-part-4-create-your-own-activity.aspx
I got two build definition that is mapped to some common folders. When I do check in it prompts me the selection box to pick up either of the build definition.
It gives me the option. Can I change my build definition to select the default based on what is triggered and show it as the first option without need for user to select the right one?
If you have two build definitions configured for the same source control folder then you will always get a choice. There is no way to set a default.
It is recommended to have only one gated-checkin configured to avoid confusion.
We are running TFS 2013 update 3 with Git - We have a powershell script that uses the output created by the BuildNumberFormat (environment variable TF_BUILD_BUILDNUMBER) that is generated at the time a build is executed. We also want to be able to queue a new build, and override that auto-generated BuildNumber, and specify a alternate (targeted hotfix for a previous tree / branch). With the default build template, there is no option to change the Build Number format (where we can statically set the desired value).
Our Build template:
Queue New Build template where we are targeting a specific changeset:
So the question is -- Do I need to edit the build work flow xaml to add this option as something that is passed in or is there a simpler way? I would like not to have to edit my power shell scripts that depend on this if we can. Ideas are greatly appreciated.
I ended up figuring it out, and it was incredibly easy. This may be an answer for similar questions also.
Copy the default build template (you can press download)
Place the file in your Repo path such as /BuildProcessTemplates/companyName.GitTemplate.12.xaml
Open the new xaml file in visual studios.
At the bottom of the screen, click the "Arguments"
Scroll down to "Metadata" and click on the edit button on the right
Scroll down to BuildNumberFormat - select it, and on the drop down "View this parameter when", change it to "Always Show the parameter"
Save the template, Commit it to your Git repo, push to your Git server.
Update your build Definition to use your new build template
You can now specify your own BuildNumber
Hope this helps someone. Looks useful for the other variables available in the build template.
I am unable to figure out how to change default build/compile settings. The little default checkbox in the lower left of the project options dialog is gone. The documentation states:
The Default checkbox that appeared at the lower edge of many Project Options pages has been removed from the product. If you want to specify options as the default for multiple projects, the suggested alternative is to use option sets instead.
I'm going round and round about "Options Sets", "Configuration Manager" etc.. Is this even possible? What does "specifying options as the default for multiple projects" mean? If I have multiple projects then that means those projects and their options exists, how can I set a default value to something already set? What about new projects?
That feature really has gone and there is nothing like it any more in the product, to the very best of my knowledge. I think the best you can do is as follows:
Create a new project.
Change the project settings to whatever you want them to be.
Change anything else in the default project that you don't like, for example { Private declarations }.
Add this project to the repository.
use File | New | Customize to move this project template onto the File | New menu for easy access.
Project->Options->Target. You can set up a base configuration, and then provide different options that differ from the base for Debug and Release. You can also create custom option sets, which means that they're different from the standard Debug and Release. You can also have different configurations based on different targets (VCL app's Debug build has different options than a FMX app's Debug build, etc.)
To change the default options first starts with defining "default". You can start as low as the "base configuration" through Project->Options->Delphi Compiler, and then choosing the All Configuration target. You can refine it somewhat by altering the base configuration for the Debug and Release configurations. You can also define your own option sets, using the Save button next to the Target list.
Your specific question about "specifying options as the default for multiple projects" means is the base configuration. From there, you refine those base options to give you debug settings and release settings (which can also be saved as your initial defaults, and refined on a per-project basis).
So, for a specific answer, you can change the default by modifying the base configuration, or by getting more specific by modifying the debug or release configurations that inherit from that base, depending on what your end result needs to be and what you're trying to accomplish.