How to trigger TFS vNext Pull Request validation build with a non default parameter value?
up vote
0
down vote
favorite
Our branch policy specifies a PR validation build. That build publishes the diagnostics binary log when system.debug is true.
But the default value for this parameter is false. In XAML builds we could trigger the Gated Check-In build with explicit shelveset and override the defaults for build parameters. But I cannot see how can one do it in vNext builds for a Pull Request.
EDIT 1
I do not want the binary log to be generated by default. The use case is when somebody's PR build fails and the reason for the failure is not immediately obvious from the build log. That is when I would like to be able to requeue the validation build with system.debug = true
tfs
azure-devops vnext edited 5 hours ago
halfer
14.3k758106
asked Nov 11 at 19:31
mark
19.3k55186373
add a comment |
up vote
0
down vote
favorite
Our branch policy specifies a PR validation build. That build publishes the diagnostics binary log when system.debug is true.
But the default value for this parameter is false. In XAML builds we could trigger the Gated Check-In build with explicit shelveset and override the defaults for build parameters. But I cannot see how can one do it in vNext builds for a Pull Request.
EDIT 1
I do not want the binary log to be generated by default. The use case is when somebody's PR build fails and the reason for the failure is not immediately obvious from the build log. That is when I would like to be able to requeue the validation build with system.debug = true
tfs
azure-devops vnext edited 5 hours ago
halfer
14.3k758106
asked Nov 11 at 19:31
mark
19.3k55186373
Why not set thesystem.debug = truein the build definition? now each build by default will be true.
– Shayki Abramczyk
Nov 11 at 20:31
1. That is not the point of the question. 2. I do not want each build to publish it diagnostics, because it takes time to generate them and time is of the essence for Gated Check-In, excuse me, PR validation builds
– mark
Nov 11 at 20:36
A quick reminder, Mark, that we prefer questions to be succinct and free of chat here. I recall I have edited your questions before to remove soliloquies about your appreciation - please try to refrain from it. The best politeness on Stack Overflow is to upvote and accept material that deserves it.
– halfer
5 hours ago
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
Our branch policy specifies a PR validation build. That build publishes the diagnostics binary log when system.debug is true.
But the default value for this parameter is false. In XAML builds we could trigger the Gated Check-In build with explicit shelveset and override the defaults for build parameters. But I cannot see how can one do it in vNext builds for a Pull Request.
EDIT 1
I do not want the binary log to be generated by default. The use case is when somebody's PR build fails and the reason for the failure is not immediately obvious from the build log. That is when I would like to be able to requeue the validation build with system.debug = true
tfs
azure-devops vnext edited 5 hours ago
halfer
14.3k758106
asked Nov 11 at 19:31
mark
19.3k55186373
Our branch policy specifies a PR validation build. That build publishes the diagnostics binary log when system.debug is true.
But the default value for this parameter is false. In XAML builds we could trigger the Gated Check-In build with explicit shelveset and override the defaults for build parameters. But I cannot see how can one do it in vNext builds for a Pull Request.
EDIT 1
I do not want the binary log to be generated by default. The use case is when somebody's PR build fails and the reason for the failure is not immediately obvious from the build log. That is when I would like to be able to requeue the validation build with system.debug = true
tfs
azure-devops vnext tfs
azure-devops vnext edited 5 hours ago
halfer
14.3k758106
asked Nov 11 at 19:31
mark
19.3k55186373
edited 5 hours ago
halfer
14.3k758106
asked Nov 11 at 19:31
mark
19.3k55186373
edited 5 hours ago
halfer
14.3k758106
edited 5 hours ago
halfer
14.3k758106
edited 5 hours ago
halfer
14.3k758106
14.3k758106
asked Nov 11 at 19:31
mark
19.3k55186373
asked Nov 11 at 19:31
mark
19.3k55186373
asked Nov 11 at 19:31
mark
19.3k55186373
19.3k55186373
Why not set thesystem.debug = truein the build definition? now each build by default will be true.
– Shayki Abramczyk
Nov 11 at 20:31
1. That is not the point of the question. 2. I do not want each build to publish it diagnostics, because it takes time to generate them and time is of the essence for Gated Check-In, excuse me, PR validation builds
– mark
Nov 11 at 20:36
A quick reminder, Mark, that we prefer questions to be succinct and free of chat here. I recall I have edited your questions before to remove soliloquies about your appreciation - please try to refrain from it. The best politeness on Stack Overflow is to upvote and accept material that deserves it.
– halfer
5 hours ago
add a comment |
Why not set thesystem.debug = truein the build definition? now each build by default will be true.
– Shayki Abramczyk
Nov 11 at 20:31
1. That is not the point of the question. 2. I do not want each build to publish it diagnostics, because it takes time to generate them and time is of the essence for Gated Check-In, excuse me, PR validation builds
– mark
Nov 11 at 20:36
A quick reminder, Mark, that we prefer questions to be succinct and free of chat here. I recall I have edited your questions before to remove soliloquies about your appreciation - please try to refrain from it. The best politeness on Stack Overflow is to upvote and accept material that deserves it.
– halfer
5 hours ago
Why not set the
system.debug = true in the build definition? now each build by default will be true.– Shayki Abramczyk
Nov 11 at 20:31
Why not set the
system.debug = true in the build definition? now each build by default will be true.– Shayki Abramczyk
Nov 11 at 20:31
1. That is not the point of the question. 2. I do not want each build to publish it diagnostics, because it takes time to generate them and time is of the essence for Gated Check-In, excuse me, PR validation builds
– mark
Nov 11 at 20:36
1. That is not the point of the question. 2. I do not want each build to publish it diagnostics, because it takes time to generate them and time is of the essence for Gated Check-In, excuse me, PR validation builds
– mark
Nov 11 at 20:36
A quick reminder, Mark, that we prefer questions to be succinct and free of chat here. I recall I have edited your questions before to remove soliloquies about your appreciation - please try to refrain from it. The best politeness on Stack Overflow is to upvote and accept material that deserves it.
– halfer
5 hours ago
A quick reminder, Mark, that we prefer questions to be succinct and free of chat here. I recall I have edited your questions before to remove soliloquies about your appreciation - please try to refrain from it. The best politeness on Stack Overflow is to upvote and accept material that deserves it.
– halfer
5 hours ago
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
I don't know if it possible out of the box, but you have a simple workaround.
Add a PowerShell task in the at the beginning of the build that set the variable system.debug to true:
Write-Host "##vso[task.setvariable variable=system.debug]true"
In the custom conditions specify that this task will be executed only in PR:
eq(variables['Build.Reason'], 'PullRequest')
answered Nov 11 at 22:20
Shayki Abramczyk
2,5621621
+1 for the creative solution, but it will make each and every PR validation build run in full debug mode. This is not what I need. I need to be able to run it for a specific PR in order to troubleshoot that PR's build.
– mark
Nov 12 at 1:54
Ohh Ok :/ maybe just create other build definitions for those PR's (with debug true)?
– Shayki Abramczyk
Nov 12 at 5:33
It does not help, because the PR is already submitted and I do not know how to trigger another build with the existing PR exactly.
– mark
Nov 12 at 12:54
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
I don't know if it possible out of the box, but you have a simple workaround.
Add a PowerShell task in the at the beginning of the build that set the variable system.debug to true:
Write-Host "##vso[task.setvariable variable=system.debug]true"
In the custom conditions specify that this task will be executed only in PR:
eq(variables['Build.Reason'], 'PullRequest')
answered Nov 11 at 22:20
Shayki Abramczyk
2,5621621
+1 for the creative solution, but it will make each and every PR validation build run in full debug mode. This is not what I need. I need to be able to run it for a specific PR in order to troubleshoot that PR's build.
– mark
Nov 12 at 1:54
Ohh Ok :/ maybe just create other build definitions for those PR's (with debug true)?
– Shayki Abramczyk
Nov 12 at 5:33
It does not help, because the PR is already submitted and I do not know how to trigger another build with the existing PR exactly.
– mark
Nov 12 at 12:54
add a comment |
up vote
1
down vote
I don't know if it possible out of the box, but you have a simple workaround.
Add a PowerShell task in the at the beginning of the build that set the variable system.debug to true:
Write-Host "##vso[task.setvariable variable=system.debug]true"
In the custom conditions specify that this task will be executed only in PR:
eq(variables['Build.Reason'], 'PullRequest')
answered Nov 11 at 22:20
Shayki Abramczyk
2,5621621
+1 for the creative solution, but it will make each and every PR validation build run in full debug mode. This is not what I need. I need to be able to run it for a specific PR in order to troubleshoot that PR's build.
– mark
Nov 12 at 1:54
Ohh Ok :/ maybe just create other build definitions for those PR's (with debug true)?
– Shayki Abramczyk
Nov 12 at 5:33
It does not help, because the PR is already submitted and I do not know how to trigger another build with the existing PR exactly.
– mark
Nov 12 at 12:54
add a comment |
up vote
1
down vote
up vote
1
down vote
I don't know if it possible out of the box, but you have a simple workaround.
Add a PowerShell task in the at the beginning of the build that set the variable system.debug to true:
Write-Host "##vso[task.setvariable variable=system.debug]true"
In the custom conditions specify that this task will be executed only in PR:
eq(variables['Build.Reason'], 'PullRequest')
answered Nov 11 at 22:20
Shayki Abramczyk
2,5621621
I don't know if it possible out of the box, but you have a simple workaround.
Add a PowerShell task in the at the beginning of the build that set the variable system.debug to true:
Write-Host "##vso[task.setvariable variable=system.debug]true"
In the custom conditions specify that this task will be executed only in PR:
eq(variables['Build.Reason'], 'PullRequest')
answered Nov 11 at 22:20
Shayki Abramczyk
2,5621621
edited Nov 12 at 8:42
answered Nov 11 at 22:20
Shayki Abramczyk
2,5621621
answered Nov 11 at 22:20
Shayki Abramczyk
2,5621621
answered Nov 11 at 22:20
Shayki Abramczyk
2,5621621
2,5621621
+1 for the creative solution, but it will make each and every PR validation build run in full debug mode. This is not what I need. I need to be able to run it for a specific PR in order to troubleshoot that PR's build.
– mark
Nov 12 at 1:54
Ohh Ok :/ maybe just create other build definitions for those PR's (with debug true)?
– Shayki Abramczyk
Nov 12 at 5:33
It does not help, because the PR is already submitted and I do not know how to trigger another build with the existing PR exactly.
– mark
Nov 12 at 12:54
add a comment |
+1 for the creative solution, but it will make each and every PR validation build run in full debug mode. This is not what I need. I need to be able to run it for a specific PR in order to troubleshoot that PR's build.
– mark
Nov 12 at 1:54
Ohh Ok :/ maybe just create other build definitions for those PR's (with debug true)?
– Shayki Abramczyk
Nov 12 at 5:33
It does not help, because the PR is already submitted and I do not know how to trigger another build with the existing PR exactly.
– mark
Nov 12 at 12:54
+1 for the creative solution, but it will make each and every PR validation build run in full debug mode. This is not what I need. I need to be able to run it for a specific PR in order to troubleshoot that PR's build.
– mark
Nov 12 at 1:54
+1 for the creative solution, but it will make each and every PR validation build run in full debug mode. This is not what I need. I need to be able to run it for a specific PR in order to troubleshoot that PR's build.
– mark
Nov 12 at 1:54
Ohh Ok :/ maybe just create other build definitions for those PR's (with debug true)?
– Shayki Abramczyk
Nov 12 at 5:33
Ohh Ok :/ maybe just create other build definitions for those PR's (with debug true)?
– Shayki Abramczyk
Nov 12 at 5:33
It does not help, because the PR is already submitted and I do not know how to trigger another build with the existing PR exactly.
– mark
Nov 12 at 12:54
It does not help, because the PR is already submitted and I do not know how to trigger another build with the existing PR exactly.
– mark
Nov 12 at 12:54
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53252410%2fhow-to-trigger-tfs-vnext-pull-request-validation-build-with-a-non-default-parame%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Why not set the
system.debug = truein the build definition? now each build by default will be true.– Shayki Abramczyk
Nov 11 at 20:31
1. That is not the point of the question. 2. I do not want each build to publish it diagnostics, because it takes time to generate them and time is of the essence for Gated Check-In, excuse me, PR validation builds
– mark
Nov 11 at 20:36
A quick reminder, Mark, that we prefer questions to be succinct and free of chat here. I recall I have edited your questions before to remove soliloquies about your appreciation - please try to refrain from it. The best politeness on Stack Overflow is to upvote and accept material that deserves it.
– halfer
5 hours ago