[JIRA] [workflow-plugin] (JENKINS-26522) Annotated block/stage status
Title: Message Title Jesse Glick commented on JENKINS-26522 Re: Annotated block/stage status Another example use case is that github-branch-source could look for the resulting status notes and publish them to the GH Status API, so you would be able to see progress of your build in different sections right in a pull request. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [workflow-plugin] (JENKINS-26522) Annotated block/stage status
Title: Message Title
Jesse Glick commented on JENKINS-26522
Re: Annotated block/stage status
I am already working on JENKINS-26107, which allows you to define a display label for a block (which could contain one step, a series of steps, some function calls, etc.). What I would propose is another step status that could take various parameters such as:
result: 'ABORTED' (or any other hudson.model.Result)
message: 'skipped 5 tests'
tags: [env: 'production', version: 123]
badge: 'url'
error: x (after catch (x))
When run, the step would look up the enclosing BlockStartNode and attach some actions to it. (The BlockEndNode would be more logical, but that is not created until the block is actually closed. Alternately, the step could be placed outside and just after the block, but that makes it harder to access local variables and the like.) So your Jenkinsfile could look like
label('Security tests') {
sh 'make test'
def failureCount = Integer.parseInt(readFile 'failureCount')
if (failureCount == 0) {
status badge: 'http://mycdn.com/checkmark.png'
} else {
status badge: 'http://mycdn.com/redx.png', result: 'UNSTABLE', message: "${failureCount} test(s) failed"
}
}
which I think is reasonably readable, and allows the job to record all relevant information in the flow graph in a way that is recoverable from the Java APIs (and, albeit awkwardly for now, from the REST API). The basic Pipeline Steps UI can certainly show all this information, and some kind of unobtrusive formatted text can be added to the textual build log too.
Then the question becomes how sophisticated you can expect the “stock” stage view visualization to be when it comes to representing this information. JENKINS-33185 proposes a significant overhaul to that view, in the context of which it would make sense to display this status information directly.
The UI you are showing requires more than that, however, since you are displaying multiple results per build according to matrix configurations. JENKINS-27395 requests a way for the Jenkinsfile to scope things like archived test results to a particular configuration of matrix axes, where this information would then become accessible to other plugins. In particular the stage view (or whatever the visualization of Pipeline builds is called by then) would need to render matrices of results when defined.
No matter what gets implemented in Pipeline, you are not going to have a UI as well tuned to your use case as what you currently have in your custom plugin, but perhaps the generic UI would be good enough, or at
[JIRA] [workflow-plugin] (JENKINS-26522) Annotated block/stage status
Title: Message Title
Jo Shields edited a comment on JENKINS-26522
Re: Annotated block/stage status
Okay, to try & better explain what we're trying to achieve, here's our current implementation, which is split into three parts:h2. Custom logic in the job shell script to annotate resultsroughly speaking, this looks like:{{STEP="System.Security-4.5"}}{{STARTTIME=`date +%s`}}{{echo "*** start: $\{STEP\}"}}{{$\{TIMEOUTCMD\} --signal=ABRT --kill-after=60s 5m make -w -C mcs/class/System.Security run-test TEST_HARNESS_FLAGS=-labels PROFILE=""> \ (date +%s \ ) - $\{STARTTIME\} | bc \ ) \ ): ${STEP}: \\e[42mPassed\e[0m" || echo -e "*** end($(echo $ \ (date +%s \ ) - $\{STARTTIME\} | bc \ ) \ ): ${STEP}: \\e[43mUnstable\e[0m"}}This assigns blocks of tests (roughly equivalent to Pipeline stages) to run together, with a common timeout, and either a "pass" status or an "unstable" status (unstable indicating this block had a non-zero exit status, but that execution of the script should continue). For steps where failure should be deemed critical, the colour code is red instead of yellow, status text says "failed", and there's some extra {{exit 1}}'s thrown in.h2, Groovy script to parse the build log and generate a job status tablePretty much just builds an HTML , pairing "*** start" and "*** end" lines to build the table structure and write the execution time, and adding the most recent test runner output as an at-a-glance summaryh2, Aggregate the data from multiple jobs in a giant table, with a custom pluginthis gives the most dense data view we can manage - 76 steps, 5 architectures, with an at-a-glance look for developers of "did I break tests grouped into X on architecture Y", or "is builder Z misbehaving and in need of attention"I would love to move as much of this crap into a Jenkinsfile as possible. Certainly parts 1 and 2 of the above seem theoretically feasible to me, but there are gaps that means I'd just end up emulating bash _really badly_ in Groovy, rather than taking advantage of Pipeline features (because the Pipeline versions are missing things)
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
You received this message because you are subscribed to the
[JIRA] [workflow-plugin] (JENKINS-26522) Annotated block/stage status
Title: Message Title
Jo Shields edited a comment on JENKINS-26522
Re: Annotated block/stage status
Okay, to try & better explain what we're trying to achieve, here's our current implementation, which is split into three parts:h2. Custom logic in the job shell script to annotate resultsroughly speaking, this looks like:{{STEP="System.Security-4.5"}}{{STARTTIME=`date +%s`}}{{echo "*** start: $\{STEP\}"}}{{$\{TIMEOUTCMD\} --signal=ABRT --kill-after=60s 5m make -w -C mcs/class/System.Security run-test TEST_HARNESS_FLAGS=-labels PROFILE="" />This assigns blocks of tests (roughly equivalent to Pipeline stages) to run together, with a common timeout, and either a "pass" status or an "unstable" status (unstable indicating this block had a non-zero exit status, but that execution of the script should continue). For steps where failure should be deemed critical, the colour code is red instead of yellow, status text says "failed", and there's some extra {{exit 1}}'s thrown in.h2 , . Groovy script to parse the build log and generate a job status tablePretty much just builds an HTML , pairing "*** start" and "*** end" lines to build the table structure and write the execution time, and adding the most recent test runner output as an at-a-glance summaryh2 , . Aggregate the data from multiple jobs in a giant table, with a custom pluginthis gives the most dense data view we can manage - 76 steps, 5 architectures, with an at-a-glance look for developers of "did I break tests grouped into X on architecture Y", or "is builder Z misbehaving and in need of attention"I would love to move as much of this crap into a Jenkinsfile as possible. Certainly parts 1 and 2 of the above seem theoretically feasible to me, but there are gaps that means I'd just end up emulating bash _really badly_ in Groovy, rather than taking advantage of Pipeline features (because the Pipeline versions are missing things)
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For
[JIRA] [workflow-plugin] (JENKINS-26522) Annotated block/stage status
Title: Message Title
Jo Shields edited a comment on JENKINS-26522
Re: Annotated block/stage status
Okay, to try & better explain what we're trying to achieve, here's our current implementation, which is split into three parts:h2. Custom logic in the job shell script to annotate resultsroughly speaking, this looks like:{{STEP="System.Security-4.5"}}{{STARTTIME=`date +%s`}}{{echo "*** start: $\{STEP\}"}}{{$\{TIMEOUTCMD\} --signal=ABRT --kill-after=60s 5m make -w -C mcs/class/System.Security run-test TEST_HARNESS_FLAGS=-labels PROFILE=""> \ ($ \ (echo $\(date +%s\) - $\{STARTTIME\} | bc\)\): $ \ {STEP \ }: \\e[42mPassed\e[0m" || echo -e "*** end \ ($ \ (echo $\(date +%s\) - $\{STARTTIME\} | bc\)\): $ \ {STEP \ }: \\e[43mUnstable\e[0m"}}This assigns blocks of tests (roughly equivalent to Pipeline stages) to run together, with a common timeout, and either a "pass" status or an "unstable" status (unstable indicating this block had a non-zero exit status, but that execution of the script should continue). For steps where failure should be deemed critical, the colour code is red instead of yellow, status text says "failed", and there's some extra {{exit 1}}'s thrown in.h2, Groovy script to parse the build log and generate a job status tablePretty much just builds an HTML , pairing "*** start" and "*** end" lines to build the table structure and write the execution time, and adding the most recent test runner output as an at-a-glance summaryh2, Aggregate the data from multiple jobs in a giant table, with a custom pluginthis gives the most dense data view we can manage - 76 steps, 5 architectures, with an at-a-glance look for developers of "did I break tests grouped into X on architecture Y", or "is builder Z misbehaving and in need of attention"I would love to move as much of this crap into a Jenkinsfile as possible. Certainly parts 1 and 2 of the above seem theoretically feasible to me, but there are gaps that means I'd just end up emulating bash _really badly_ in Groovy, rather than taking advantage of Pipeline features (because the Pipeline versions are missing things)
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
You received this message because you are
[JIRA] [workflow-plugin] (JENKINS-26522) Annotated block/stage status
Title: Message Title
Jo Shields edited a comment on JENKINS-26522
Re: Annotated block/stage status
Okay, to try & better explain what we're trying to achieve, here's our current implementation, which is split into three parts:h2. Custom logic in the job shell script to annotate resultsroughly speaking, this looks like:{{STEP="System.Security-4.5"}}{{STARTTIME=`date +%s`}}{{echo "*** start: $\{STEP\}"}}{{$ \ {TIMEOUTCMD \ } --signal=ABRT --kill-after=60s 5m make -w -C mcs/class/System.Security run-test TEST_HARNESS_FLAGS=-labels PROFILE=""> \ {STARTTIME \ } | bc)): ${STEP}: \e[42mPassed\e[0m" || echo -e "*** end($(echo $(date +%s) - $ \ {STARTTIME \ } | bc)): ${STEP}: \e[43mUnstable\e[0m"}}This assigns blocks of tests (roughly equivalent to Pipeline stages) to run together, with a common timeout, and either a "pass" status or an "unstable" status (unstable indicating this block had a non-zero exit status, but that execution of the script should continue). For steps where failure should be deemed critical, the colour code is red instead of yellow, status text says "failed", and there's some extra {{exit 1}}'s thrown in.h2, Groovy script to parse the build log and generate a job status tablePretty much just builds an HTML , pairing "*** start" and "*** end" lines to build the table structure and write the execution time, and adding the most recent test runner output as an at-a-glance summaryh2, Aggregate the data from multiple jobs in a giant table, with a custom pluginthis gives the most dense data view we can manage - 76 steps, 5 architectures, with an at-a-glance look for developers of "did I break tests grouped into X on architecture Y", or "is builder Z misbehaving and in need of attention"I would love to move as much of this crap into a Jenkinsfile as possible. Certainly parts 1 and 2 of the above seem theoretically feasible to me, but there are gaps that means I'd just end up emulating bash _really badly_ in Groovy, rather than taking advantage of Pipeline features (because the Pipeline versions are missing things)
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
You received this message because you are subscribed to the Google Groups "Jenkins
[JIRA] [workflow-plugin] (JENKINS-26522) Annotated block/stage status
Title: Message Title
Jo Shields edited a comment on JENKINS-26522
Re: Annotated block/stage status
Okay, to try & better explain what we're trying to achieve, here's our current implementation, which is split into three parts:h2. Custom logic in the job shell script to annotate resultsroughly speaking, this looks like:{{STEP="System.Security-4.5"}}{{STARTTIME=`date +%s`}}{{echo "*** start: $\{STEP\}"}}{{$\{TIMEOUTCMD\} --signal=ABRT --kill-after=60s 5m make -w -C mcs/class/System.Security run-test TEST_HARNESS_FLAGS=-labels PROFILE=""> \ e[42mPassed\e[0m" || echo -e "*** end($(echo $(date +%s) - $\{STARTTIME\} | bc)): ${STEP}: \ \ e[43mUnstable\e[0m"}}This assigns blocks of tests (roughly equivalent to Pipeline stages) to run together, with a common timeout, and either a "pass" status or an "unstable" status (unstable indicating this block had a non-zero exit status, but that execution of the script should continue). For steps where failure should be deemed critical, the colour code is red instead of yellow, status text says "failed", and there's some extra {{exit 1}}'s thrown in.h2, Groovy script to parse the build log and generate a job status tablePretty much just builds an HTML , pairing "*** start" and "*** end" lines to build the table structure and write the execution time, and adding the most recent test runner output as an at-a-glance summaryh2, Aggregate the data from multiple jobs in a giant table, with a custom pluginthis gives the most dense data view we can manage - 76 steps, 5 architectures, with an at-a-glance look for developers of "did I break tests grouped into X on architecture Y", or "is builder Z misbehaving and in need of attention"I would love to move as much of this crap into a Jenkinsfile as possible. Certainly parts 1 and 2 of the above seem theoretically feasible to me, but there are gaps that means I'd just end up emulating bash _really badly_ in Groovy, rather than taking advantage of Pipeline features (because the Pipeline versions are missing things)
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this
[JIRA] [workflow-plugin] (JENKINS-26522) Annotated block/stage status
Title: Message Title
Jo Shields edited a comment on JENKINS-26522
Re: Annotated block/stage status
Okay, to try & better explain what we're trying to achieve, here's our current implementation, which is split into three parts:h2. Custom logic in the job shell script to annotate resultsroughly speaking, this looks like:{{STEP="System.Security-4.5" }} {{ STARTTIME=`date +%s` }} {{ echo "*** start: $ \ {STEP \ }" }} {{ ${TIMEOUTCMD} --signal=ABRT --kill-after=60s 5m make -w -C mcs/class/System.Security run-test TEST_HARNESS_FLAGS=-labels PROFILE="" />This assigns blocks of tests (roughly equivalent to Pipeline stages) to run together, with a common timeout, and either a "pass" status or an "unstable" status (unstable indicating this block had a non-zero exit status, but that execution of the script should continue). For steps where failure should be deemed critical, the colour code is red instead of yellow, status text says "failed", and there's some extra {{exit 1}}'s thrown in.h2, Groovy script to parse the build log and generate a job status tablePretty much just builds an HTML , pairing "*** start" and "*** end" lines to build the table structure and write the execution time, and adding the most recent test runner output as an at-a-glance summaryh2, Aggregate the data from multiple jobs in a giant table, with a custom pluginthis gives the most dense data view we can manage - 76 steps, 5 architectures, with an at-a-glance look for developers of "did I break tests grouped into X on architecture Y", or "is builder Z misbehaving and in need of attention"I would love to move as much of this crap into a Jenkinsfile as possible. Certainly parts 1 and 2 of the above seem theoretically feasible to me, but there are gaps that means I'd just end up emulating bash _really badly_ in Groovy, rather than taking advantage of Pipeline features (because the Pipeline versions are missing things)
Add Comment
This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
[JIRA] [workflow-plugin] (JENKINS-26522) Annotated block/stage status
Title: Message Title
Jo Shields updated an issue
Jenkins / JENKINS-26522
Annotated block/stage status
Okay, to try & better explain what we're trying to achieve, here's our current implementation, which is split into three parts:
Custom logic in the job shell script to annotate results
roughly speaking, this looks like:
{{STEP="System.Security-4.5" STARTTIME=`date +%s` echo "*** start: $ {STEP}" ${TIMEOUTCMD} --signal=ABRT --kill-after=60s 5m make -w -C mcs/class/System.Security run-test TEST_HARNESS_FLAGS=-labels PROFILE="" && echo -e "*** end($(echo $(date +%s) - ${STARTTIME} | bc)): ${STEP}
: \e[42mPassed\e[0m" || echo -e "*** end($(echo $(date +%s) - $ {STARTTIME}
| bc)): $ {STEP}
: \e[43mUnstable\e[0m"}}
This assigns blocks of tests (roughly equivalent to Pipeline stages) to run together, with a common timeout, and either a "pass" status or an "unstable" status (unstable indicating this block had a non-zero exit status, but that execution of the script should continue). For steps where failure should be deemed critical, the colour code is red instead of yellow, status text says "failed", and there's some extra exit 1's thrown in.
h2, Groovy script to parse the build log and generate a job status table
Pretty much just builds an HTML , pairing "*** start" and "*** end" lines to build the table structure and write the execution time, and adding the most recent test runner output as an at-a-glance summary
h2, Aggregate the data from multiple jobs in a giant table, with a custom plugin
this gives the most dense data view we can manage - 76 steps, 5 architectures, with an at-a-glance look for developers of "did I break tests grouped into X on architecture Y", or "is builder Z misbehaving and in need of attention"
I would love to move as much of this crap into a Jenkinsfile as possible. Certainly parts 1 and 2 of the above seem theoretically feasible to me, but there are gaps that means I'd just end up emulating bash really badly in Groovy, rather than taking advantage of Pipeline features (because the Pipeline versions are missing things)
Change By:
Jo Shields
Attachment:
Screenshot from 2016-04-05 14-30-24.png
Attachment:
[JIRA] [workflow-plugin] (JENKINS-26522) Annotated block/stage status
Title: Message Title Jesse Glick commented on JENKINS-26522 Re: Annotated block/stage status A related request was for a stage to be marked with a custom icon, to indicate what kind of stage this way, or to add some key/value pairs such as name of environment we deployed to. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [workflow-plugin] (JENKINS-26522) Annotated block/stage status
Title: Message Title Jesse Glick updated an issue Jenkins / JENKINS-26522 Annotated block/stage status Change By: Jesse Glick Summary: Annotatedblock results /stagestatus Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
