[JIRA] (JENKINS-39138) no change in groovy still causes job xml to change
Title: Message Title boris ivan commented on JENKINS-39138 Re: no change in groovy still causes job xml to change Hi Mike Chmielewski will this be something that gets released? Filling up our logs and could really use it. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.175559.1476960234000.18259.1587994320155%40Atlassian.JIRA.
[JIRA] (JENKINS-18666) Submodule reference
Title: Message Title boris ivan updated an issue Jenkins / JENKINS-18666 Submodule reference Change By: boris ivan Method underlined textMethod `submoduleUpdate` should accept `reference` the same way as `clone` does.git submodule update --init --recursive --reference $referenceSpeeds up submodule update when using a local mirror. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.150014.1373318147000.4414.1582304940420%40Atlassian.JIRA.
[JIRA] (JENKINS-55849) cannot stop auto-scrolling in blue ocean console
Title: Message Title boris ivan commented on JENKINS-55849 Re: cannot stop auto-scrolling in blue ocean console Hi Pete Moore – for me, using the scroll bar doesn't work, though I found that if I use the mouse wheel first, it works. Specifically: assuming I've clicked on an active stage, then opened the text box for the step that's active, it will auto scroll and keep focus at the bottom. At that point, if I do nothing other than attempt to use the scroll bar to bring the pipeline back into view (i.e. at the top of the browser window that was otherwise scrolled out of view because of all the text in the text box) – as soon as I release the scroll bar, it would jump back down to the bottom of the text window, as soon as the next log message was printed. But what I've found since then, is that while I'm at the bottom of the active text box – if I use the middle mouse button to scroll up a few lines, that 'breaks' the connection such that I can subsequently use the scroll bar controls, or continue to use the middle mouse button, or anything, and it won't auto-jump back down to the bottom of the text window when the next log message appears. But without using that middle mouse button first, using the scroll bar controls would allow me to move up but as soon as I let go, it jumped back down. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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. To view this discussion on the web visit
[JIRA] (JENKINS-58190) timeout on parallel sequential stage killed processes in the wrong stage!
Title: Message Title boris ivan created an issue Jenkins / JENKINS-58190 timeout on parallel sequential stage killed processes in the wrong stage! Issue Type: Bug Assignee: Unassigned Components: pipeline Created: 2019-06-25 15:57 Priority: Blocker Reporter: boris ivan I have a pipeline with parallel sequential stages. In one of the sequential stages (that has multiple 'stages'), there was a stage that had a timeout of 20 minutes. That stage took too long, but instead of it being aborted – a different stage had a process killed – a maven build running in a different parallel sequential stream abruptly aborted. Something in parallel stages isn't being tracked properly in the pipeline, I think. once my pipeline gets to the "testing" phase, there are a few parallel stages (some of which have multiple stages), like this: a--b--c -d-e- ---g--- ---h--- ---i In my case, b had a timeout of 20 minutes. But it ran for 24 with nothing stopping it – the stage is a shell script step running a suite of npm/node.js tests. At the 24 minute mark when it finished normally (but should have been aborted at 20 minutes!!), stage e abruptly had it's maven surefire unit tests abort mid-suite. It's at exactly the same time that stage b finished (which should have aborted earlier) It's as if the code set to kill the processes due to the timeout was delayed ignored by stage "b", and then stage "e" ended up being the victim.
[JIRA] (JENKINS-53816) [Blue Ocean] Completed stages appear to be skipped instead of finished
Title: Message Title boris ivan edited a comment on JENKINS-53816 Re: [Blue Ocean] Completed stages appear to be skipped instead of finished Hi [~sophistifunk] -- I can confirm that some completed stages are still showing as transparent, in Blue Ocean 1.17.I think that some parallel stages that had a _single_ stage were previously not showing correctly sometimes, and that seems to have improved.But a stage that has parallel stages that each have _sequential_ stages in them are still showing as transparent when complete, though as before, it paints correctly as soon as the pipeline finishes.For example:---ab---c|---de---fIf d completes, it shows as transparent (incorrect). I'm also now seeing that if " e does show " is active, it sometimes doesn't have the blue animation showing as active (which is correct) . Things may have gotten worse. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.194330.153804945.24608.1560184380514%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-53816) [Blue Ocean] Completed stages appear to be skipped instead of finished
Title: Message Title boris ivan edited a comment on JENKINS-53816 Re: [Blue Ocean] Completed stages appear to be skipped instead of finished Hi [~sophistifunk] -- I can confirm that some completed stages are still showing as transparent, in Blue Ocean 1.17.I think that some parallel stages that had a single _single_ stage were previously not showing correctly sometimes, and that seems better to have improved .But a stage that has parallel stages that each have _sequential_ stages in them are still showing as transparent when complete, though as before, it paints correctly as soon as the pipeline finishes.For example:---ab---c|---de---fIf d completes, it shows as transparent (incorrect). e does show as active (which is correct). Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.194330.153804945.24591.1560182820174%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-53816) [Blue Ocean] Completed stages appear to be skipped instead of finished
Title: Message Title boris ivan edited a comment on JENKINS-53816 Re: [Blue Ocean] Completed stages appear to be skipped instead of finished Hi [~sophistifunk] -- I can confirm that some completed stages are still showing as parallel transparent , in Blue Ocean 1.17.I think that some parallel stages that had a single stage were previously not showing correctly sometimes, and that seems better.But a stage that has parallel stages that each have _sequential_ stages in them are still showing as transparent when complete, though as before, it paints correctly as soon as the pipeline finishes.For example:---ab---c|---de---fIf d completes, it shows as transparent (incorrect). e does show as active (which is correct). Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.194330.153804945.24586.1560182760206%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-53816) [Blue Ocean] Completed stages appear to be skipped instead of finished
Title: Message Title boris ivan commented on JENKINS-53816 Re: [Blue Ocean] Completed stages appear to be skipped instead of finished Hi Josh McDonald – I can confirm that completed stages are still showing as parallel, in Blue Ocean 1.17. I think that some parallel stages that had a single stage were previously not showing correctly sometimes, and that seems better. But a stage that has parallel stages that each have sequential stages in them are still showing as transparent when complete, though as before, it paints correctly as soon as the pipeline finishes. For example: --a--b--c --d--e--f If d completes, it shows as transparent (incorrect). e does show as active (which is correct). Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.194330.153804945.24515.1560175560206%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-39203) All stages show up as UNSTABLE when only one stage should
Title: Message Title boris ivan commented on JENKINS-39203 Re: All stages show up as UNSTABLE when only one stage should I can understand the existing logic and methodology makes this difficult to change. But I don't understand why something simple like this couldn't be done as a workaround: add a new property (doesn't exist today) to each stage object: stageIndependentStatus when each stage completes, immediately save the value of the independent execution of that stage in stageIndependentStatus This way, you can let all the existing logic stay as-is regarding stage state, state propagation to other stages, etc – all the things that are difficult to change. The "overall build" would still be marked as it is today. Nothing needs to change. But with that separate property being available per stage, visualizers like blue ocean could implement a configuration: "showStageLegacyStatus" or "showStageIndependentStatus", defined in the options for a pipeline. If the user chooses the latter, visualizers like blue ocean could make their own choice to paint strictly by the stageIndependentStatus. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-56880) blue ocean tests page shows stale data after clicked
Title: Message Title boris ivan created an issue Jenkins / JENKINS-56880 blue ocean tests page shows stale data after clicked Issue Type: Bug Assignee: Unassigned Components: blueocean-plugin Created: 2019-04-04 12:18 Environment: chrome browser on windows, blue ocean 1.13 Priority: Critical Reporter: boris ivan I have a declarative pipeline that runs for hours and has many stages relates to testing. During execution, some of the test stages were complete and some had some test failures. I clicked the 'tests' link at the top of the blue ocean pipeline UI view, and it showed the failing tests – so far so good. A couple hours later, the pipeline finished, which included the completion of a couple more stages dedicated to testing. From the pipeline view, I clicked on the 'tests' link again, and it brought me to the page showing the failing and passing tests. The list of failing tests did not include 2 new failed tests that I knew should be in there. I refreshed my browser and this time the new failing tests showed up. It appears that if the tests tab is examined mid pipeline, then if one goes back to the blue ocean pipeline UI view and then clicks the tests tab again after more stages complete, clicking on the tests tab again shows old data. Marking as critical because there is nothing more dangerous than showing what appears to be a list of failing tests... but it doesn't include a subset of failing tests.
[JIRA] (JENKINS-56672) Artifacts tab in blue ocean does not have link to view an artifact
Title: Message Title boris ivan commented on JENKINS-56672 Re: Artifacts tab in blue ocean does not have link to view an artifact I've always had mixed results re: that working even in the legacy UI, and found that it was client/chrome related, re: displaying the content vs downloading. I mention this because it's working for me right now with blueocean. If I click "artifacts" I see a list of 3 items: pipeline.log, and two .png files generated as screenshots from UI testing, that I publish with the 'archive the artifacts' functionality. Each of those 3 items is a link itself as far as the "filename" is concerned, To the right of the filename is size, and to the right of that is the icon/link (down arrow) for downloading. Each work as expected for me – clicking on the "filename" displays the object in the browser in a new tab pipeline.log shows all the build text, and the two .png files show the picture. If I click the download icon it will download it. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-46193) New test failures are reported as both new test failures and existing test failures.
Title: Message Title boris ivan commented on JENKINS-46193 Re: New test failures are reported as both new test failures and existing test failures. Same here. I have so many people ask me about this when I send them links to that test page. For this to be the case since 2017 seems avoidable. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-55605) can only click on the first active parallel stage, others running but cannot click
Title: Message Title boris ivan commented on JENKINS-55605 Re: can only click on the first active parallel stage, others running but cannot click Also note odd behavior re: "git:c2" in the picture attached. After running the pipeline multiple times, stages start to not render correctly at all (transparent), even though they're active (and sometimes, completed). They all correctly render when the pipeline is complete. But mid pipeline, they are broken. Possibly not related to this JIRA, but since it's in the same picture (and I don't know how to reliably replicate) – just mentioning it in case it generates any ideas... Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-55605) can only click on the first active parallel stage, others running but cannot click
Title: Message Title boris ivan commented on JENKINS-55605 Re: can only click on the first active parallel stage, others running but cannot click added an attachment illustrating the problem. In the picture, I cannot get the context of the lower half of the window (i.e. where the steps / build console is) to switch to the active stage "git:e" (or "git:s1"). The only active stage I can click on (and see the context change) is "git:b". However, when the 'leftmost' stages were all active at the beginning of the pipeline, I could click on any of them, and the context would change correctly. It is only when the leftmost stages complete, that the active stage to the right is 'unclickable'. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-55605) can only click on the first active parallel stage, others running but cannot click
Title: Message Title boris ivan updated an issue Jenkins / JENKINS-55605 can only click on the first active parallel stage, others running but cannot click Change By: boris ivan Attachment: uiProblem.jpg Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-55605) can only click on the first active parallel stage, others running but cannot click
Title: Message Title boris ivan updated an issue Jenkins / JENKINS-55605 can only click on the first active parallel stage, others running but cannot click Change By: boris ivan Attachment: uiProblem.jpg Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-56639) when viewing a pipeline in blue ocean, please stop auto opening console log of failed step
Title: Message Title boris ivan created an issue Jenkins / JENKINS-56639 when viewing a pipeline in blue ocean, please stop auto opening console log of failed step Issue Type: Improvement Assignee: Unassigned Components: blueocean-plugin Created: 2019-03-20 14:51 Priority: Minor Reporter: boris ivan If I look at multiple pipeline executions by using the "<" or ">" buttons (or any mechanism), the graph starts to draw but then it all disappears because the loading automates opening the build log of a failed step, and most users's build logs are at least a few pages long, which pushes the pipeline visualization off the screen. This is a poor UI experience. I understand the intent – it's a convenience to bring attention to a failed step, I suppose. A better user experience would be: highlight the failed stage on the graph, and maybe even highlight the failed 'step' in the list of steps, but leave that step log widget collapsed – don't auto-expand it, which is what is ruining the UI experience. Add Comment
[JIRA] (JENKINS-39203) All stages show up as UNSTABLE when only one stage should
Title: Message Title boris ivan commented on JENKINS-39203 Re: All stages show up as UNSTABLE when only one stage should added an attachment 'allYellow.jpg' to illustrate the impact. The various grouping of 12 stages on the right of the pipeline are all test related. Before the pipeline got that far – everything was green, as all those previous stages were successful. And for the 12 test related stages on the right... 2 of them had some failures, the other 10 had no failures. But examining a visualization to get a good understand of what went well and what had issues.. all value is lost, nothing has meaning. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-39203) All stages show up as UNSTABLE when only one stage should
Title: Message Title boris ivan updated an issue Jenkins / JENKINS-39203 All stages show up as UNSTABLE when only one stage should Change By: boris ivan Attachment: allYellow.jpg Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-56371) pipelines with more than 1 stage that publishes tests results in multiple "+ no issue" links per test
Title: Message Title boris ivan created an issue Jenkins / JENKINS-56371 pipelines with more than 1 stage that publishes tests results in multiple "+ no issue" links per test Issue Type: Bug Assignee: Catalin Luta Components: jiratestresultreporter-plugin Created: 2019-03-03 18:22 Priority: Major Reporter: boris ivan I have a pipeline that has multiple stages, and more than 1 of them has a junit publish step. The tests in those stages are all unique. When the pipeline is complete and I examine the test report, I notice that each failed test has 5 "+ no issue" links on the line for that test. I think that's the same number of stages that publish junit results, even though each test only exists in 1 stage. It looks like the logic that adds the "+ no issue" link must be adding it multiple times, in the scenario where a pipeline has multiple stages that have a junit publisher. Add Comment
[JIRA] (JENKINS-56370) context specific field not working with jiratestresultreporter-plugin
Title: Message Title
boris ivan created an issue
Jenkins / JENKINS-56370
context specific field not working with jiratestresultreporter-plugin
Issue Type:
Bug
Assignee:
Catalin Luta
Components:
jiratestresultreporter-plugin
Created:
2019-03-03 18:11
Priority:
Major
Reporter:
boris ivan
When trying to create an issue from the test report, a JIRA field that is context-related to a different JIRA field couldn't be set. Specifically, in the UI our 'create' screen has a few custom required fields. Two of these fields have a relationship, we have a field with a text label: "Major Area" and another field with text label "Component", both are dropdown lists of selectable values. In the JIRA UI, once I select a value for the "Major Area" field, it changes the various selectable choices for "Component". Looking at the html source, these fields have have the following values for name and id: "Major Area" – has name and id: "customfield_11100" "Component" – has name and id: "customfield_11100:1" There are other required fields (without the 'relationship' described above) that also have name/id similar to above, like "customfield_11101" and "customfield_11102", and when I wasn't setting them properly with this plugin, the plugin would show that JIRA was sending a 400 error, complaining that the fields weren't set, and I've now set those properly and those errors have stopped, so I believe I'm configuring the values for this plugin correctly. But the context-dependent field "Component" (name/id in the html shows as customfield_11100:1) doesn't want to cooperate. Here's the error I receive from this plugin, when setting that value: Error when creating issue RestClientException{statusCode=Optional.of(400), errorCollections=[ErrorCollection{status=400, errors= {customfield_11100:1=Field 'customfield_11100:1' cannot be set. It is not on the appropriate screen, or unknown.} , errorMessages=[]}]} Here's what my pipeline syntax looks like: junit ( allowEmptyResults: true, testResults:
[JIRA] (JENKINS-39203) All stages show up as UNSTABLE when only one stage should
Title: Message Title boris ivan edited a comment on JENKINS-39203 Re: All stages show up as UNSTABLE when only one stage should I understand that the job status and logic associated with the overall job status is established throughout Jenkins and that's difficult to adjust. (at least that's what I've heard the problem is, re: 'fixing' this). But in the meantime, can't we just leave that logic alone, and create a new property for the stage object, called 'stage status', that is limited in scope to the execution of that specific stage, and give the user an option to use legacy behavior, or display per-stage-status? The 'overall' job status logic could remain the same.To ignore the entire user base screaming about this about to drive me away, and is so different from the great experience and responsiveness I've had with the Jenkins team over the years. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-39203) All stages show up as UNSTABLE when only one stage should
Title: Message Title boris ivan commented on JENKINS-39203 Re: All stages show up as UNSTABLE when only one stage should I understand that the job status and logic associated with the job status is established throughout Jenkins and that's difficult to adjust. (at least that's what I've heard the problem is, re: 'fixing' this). But in the meantime, can't we just leave that logic alone, and create a new property for the stage object, called 'stage status', that is limited in scope to the execution of that specific stage, and give the user an option to use legacy behavior, or display per-stage-status? The 'overall' job status logic could remain the same. To ignore the entire user base screaming about this about to drive me away, and is so different from the great experience and responsiveness I've had with the Jenkins team over the years. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-56171) blue ocean pipeline cache misleading, at least needs a mechanism to clear
Title: Message Title boris ivan created an issue Jenkins / JENKINS-56171 blue ocean pipeline cache misleading, at least needs a mechanism to clear Issue Type: Bug Assignee: Unassigned Components: blueocean-plugin Created: 2019-02-17 18:02 Priority: Major Reporter: boris ivan I'm actively working on a pipeline. Occasionally I will delete or move a stage, in the effort to working on this pipeline (using declarative). When I run the pipeline again, I see various stages that I've already deleted. Sometimes they even go green and move on to the next stage. In all cases, when the pipeline finishes, the correct view is painted, and the ghost stages disappear. But this is a real problem. Our pipelines take hours to run - it's not a quick couple of seconds in which the incorrect graph is drawn. I've seen debate across various JIRAs in which the developers mentioned they aren't planning on removing the cache because some users might like it. I disagree, but you can't please everyone. However, given that using the cache shows blatantly incorrect visualizations, a fix needs to be provided. I think it should always work and if that means not using the cache at all I'd be happy, but to appease everyone, maybe you can provide an optional way to clear the cache before the next run, to appease the group of us who need the visualization to not be wrong.
[JIRA] (JENKINS-55605) can only click on the first active parallel stage, others running but cannot click
Title: Message Title boris ivan commented on JENKINS-55605 Re: can only click on the first active parallel stage, others running but cannot click Tried again, and things seem the same as prior to 1.11.1, so I'm not sure there was slight improvement. In either case, still broken. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-55605) can only click on the first active parallel stage, others running but cannot click
Title: Message Title boris ivan commented on JENKINS-55605 Re: can only click on the first active parallel stage, others running but cannot click some improvement in BO 1.11.1 – I can now click on S1, S2, S3, S5, and context changes accordingly. Prior to BO 1.11.1 I could only see the context of S1 regardless what I clicked. Unfortunately when S5 finishes and the active stages are: S1, S2, S3, S6 ... I cannot click on S6 and have the context switch to S6. The blue active icon gets larger, but the context (logs, etc) doesn't switch. So.. things are a bit better, but still broke. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-55849) cannot stop auto-scrolling in blue ocean console
Title: Message Title boris ivan created an issue Jenkins / JENKINS-55849 cannot stop auto-scrolling in blue ocean console Issue Type: Bug Assignee: Unassigned Components: blueocean-plugin Created: 2019-01-29 21:14 Environment: 1.10.2 Priority: Minor Reporter: boris ivan When I have console for an active stage open, I see the new messages added real-time to the bottom of the console window, so far so good. But if I want to scroll up to see messages printed a couple seconds ago, or scroll up so I can collapse the console window so I can view the pipeline, I'm prevented from doing so because every new log message forces the focus back down to the bottom. In legacy Jenkins, being at the bottom of the window would continue to update, but if the user scrolled up away from the bottom, it would not force focus back down to the bottom with every new message. When the messages come quickly, I'm forced to spam the 'home' key on the keyboard to try and jump up to the top and click the 'collapse' icon as quickly as possible, but not usually not quick enough. There should be some standardized way of preventing the auto scroll.
[JIRA] (JENKINS-39203) All stages show up as UNSTABLE when only one stage should
Title: Message Title boris ivan commented on JENKINS-39203 Re: All stages show up as UNSTABLE when only one stage should Was so excited to move our production builds to using the pipeline and blue ocean visualization. With all the stages changing from green to unstable, it's a blocker. Even posting each stage status to slack becomes misleading, in that healthy stages post unstable, and there are instances of unstable stages posting as success, that's a deal breaker right off the bat. Can I suggest a short term workaround? If there was an option in the pipeline: "stageStatus=independent" (or something like that), which worked this way, it would allow us to have control and use blue ocean until it's resolved: simply allow each stage icon to use the color/state of it's own independent activity That's it. I'm not sure if that's a flowNode or what, but whatever each icon is in any stage, they all seem to be capable (today) of executing and knowing if that execution was successful or unstable or failure or aborted. If that can simply be retained and displayed for that icon, this works for me. As far as what the overall build status ends up as in this case – if you allow us to set it at the end of the pipeline, we could code that to our own needs, based on the individual statuses per stage. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-55605) can only click on the first active parallel stage, others running but cannot click
Title: Message Title boris ivan updated an issue Jenkins / JENKINS-55605 can only click on the first active parallel stage, others running but cannot click Change By: boris ivan I have a pipeline with parallel sequential stages (the same problem might occur if there are parallel 1-stage, not sure) and can only click on the first 'active' stage. Too much to obfuscate, will do ascii: 4 parallel - sequential stages below: r--- s1 --- | . |--- s2 --- | . |--- s3 — ... s4 ... | . L--- s5 — s6 s4 and s6 included in the diagram in case it's relevant, but the problem happens without them being shown visually in what I'm about to describe, as those stages haven't started yet:s1 is a single stage and complete (green)s2, s3, s5 all show as animated blue circles, which is accurate. Going out of blue ocean and examining legacy pipeline view properly shows logs progressing on those.But in the blue ocean view, I can only click on s1, or s2, and have the bottom half of the screen (console log, etc) update. s3 and s5 on hover-over show that they're clickable, but clicking them does nothing. Only clicking s1 or s2 changes the context of the bottom half of the blue ocean UI.Potentially of interest:If I'm currently clicked/selected on s2, then clicking s3/s5 does nothing.If I'm currently clicked/selected on s1 (the one that is green/complete), then clicking on s3/s5 changes the bottom context to *s2*.It's as is clicking on any active parallel stage will only set the bottom context to the first _active_ parallel stage, but that is just a guess.As I write this – the graph has now progressed so that s2, s4, and s6 are active. s1, s3, and s5 are complete. Still has the same problem – if I click on s4 or s6, it only shows the context of s2. Add Comment
[JIRA] (JENKINS-55605) can only click on the first active parallel stage, others running but cannot click
Title: Message Title boris ivan created an issue Jenkins / JENKINS-55605 can only click on the first active parallel stage, others running but cannot click Issue Type: Bug Assignee: Unassigned Components: blueocean-plugin Created: 2019-01-15 19:24 Environment: blueocean 1.10.1, all browsers Priority: Major Reporter: boris ivan I have a pipeline with parallel sequential stages (the same problem might occur if there are parallel 1-stage, not sure) and can only click on the first 'active' stage. Too much to obfuscate, will do ascii: r--s1-- --s2--
[JIRA] (JENKINS-55588) blue ocean test results page lists passing tests, not failing ones
Title: Message Title boris ivan created an issue Jenkins / JENKINS-55588 blue ocean test results page lists passing tests, not failing ones Issue Type: Bug Assignee: Unassigned Components: blueocean-plugin Created: 2019-01-14 23:12 Environment: chrome, jenkins 2.157 blue ocean 1.10.1 Priority: Major Reporter: boris ivan In the blue ocean 'tests' link for that execution, I'm used to seeing the failed tests, then skipped, then passing. Today, I see a correct summary re: the qty of tests failed, but with no section of test names, etc. If I go to the non-blue-ocean pipeline step view, I see the names of the failed tests, all test reporting looking good. But in the blue-ocean-ui view (I've just copied and pasted the text from that view, below) – no list of failed test names. 173 tests have failed There are 152 new tests failing, 21 existing failing and 83 skipped. New failing - 152 Existing failures - 21 Fixed 26 Skipped - 83 (here, a list of skipped tests) Passed - 17983 (here, a list of passing tests) Add Comment
[JIRA] (JENKINS-55427) Blue Ocean display of sequential stages in parallel stages is flaky
Title: Message Title boris ivan commented on JENKINS-55427 Re: Blue Ocean display of sequential stages in parallel stages is flaky We see the same flaky behavior, re: nodes complete but not showing as complete (and often not clickable). Also, note the truncation in the picture you've attached, re: the name of that stage. The truncation of that stage name is too aggressive, making it useless (https://issues.jenkins-ci.org/browse/JENKINS-55393) Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-55393) blue ocean stage name truncation for parallel sequential is too aggressive
Title: Message Title boris ivan created an issue Jenkins / JENKINS-55393 blue ocean stage name truncation for parallel sequential is too aggressive Issue Type: Bug Assignee: Unassigned Attachments: truncated.jpg Components: blueocean-plugin Created: 2019-01-03 16:26 Environment: Jenkins 2.156 Blue Ocean 1.10.1 rendered in chrome and edge Priority: Minor Reporter: boris ivan The UI in blue ocean 1.10.1 now supports showing the stage name for parallel sequential stages. Unfortunately, everything ends up truncated. In the picture I'm attaching (please forgive the obfuscation, I know it doesn't help the illustration...), note the parallel sequential stages. All of them are truncated, and most are very small in terms of the length of the overall string. I can understand the need to truncate if the string is too large, but some of my strings are only a few characters long in total. For example, note the one on the bottom of the first parallel section. While I'm not using the real words here (obfuscation), it is 3 words, each exactly this long: "hi one four" In the UI, I see: "hi one ..." I think allowing them to spread across 2 vertical lines would work great, even if the overall width wouldn't change, like this: hi one four .. I don't think it would encroach on the parallel sequential above/below it. I'm sure there is a balance you need to strike, but I can't get anything to not truncate, even phrases as small as described above.
[JIRA] (JENKINS-53816) [Blue Ocean] Completed stages appear to be skipped instead of finished
Title: Message Title boris ivan edited a comment on JENKINS-53816 Re: [Blue Ocean] Completed stages appear to be skipped instead of finished slight correction: my pipeline is still running, but otherwise is as described above at this point. The downstream steps that were complete are now completely missing in the visualization. The parallel-sequential step updated to show all complete (they were all complete ~ 40 minutes earlier, in reality). When the UI update occurred for that, that's when the downstream sequential steps that had previously run and completed (and were shown) disappeared. The pipeline is now on a step further downstream and it's running, though it's not shown _anywhere_. I suspect that when the entire pipeline is complete, it will all reappear, as I think I saw that occur before. update: as suspected. The entire pipeline shows upon completion, including the steps that had shown before that went away mid pipeline as described above. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-53816) [Blue Ocean] Completed stages appear to be skipped instead of finished
Title: Message Title boris ivan commented on JENKINS-53816 Re: [Blue Ocean] Completed stages appear to be skipped instead of finished slight correction: my pipeline is still running, but otherwise is as described above at this point. The downstream steps that were complete are now completely missing in the visualization. The parallel-sequential step updated to show all complete (they were all complete ~ 40 minutes earlier, in reality). When the UI update occurred for that, that's when the downstream sequential steps that had previously run and completed (and were shown) disappeared. The pipeline is now on a step further downstream and it's running, though it's not shown anywhere. I suspect that when the entire pipeline is complete, it will all reappear, as I think I saw that occur before. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-53816) [Blue Ocean] Completed stages appear to be skipped instead of finished
Title: Message Title boris ivan updated an issue Jenkins / JENKINS-53816 [Blue Ocean] Completed stages appear to be skipped instead of finished Change By: boris ivan Priority: Minor Major Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-53816) [Blue Ocean] Completed stages appear to be skipped instead of finished
Title: Message Title boris ivan commented on JENKINS-53816 Re: [Blue Ocean] Completed stages appear to be skipped instead of finished I'm seeing similar but even worse – the 'parallel sequential' stage that I have (similar to the picture attached) is in the beginning of my pipeline, and there are other steps afterwards. My build is currently executing those 'later' steps, showing blank circles for some of the steps that I know were finished earlier, in the 'parallel sequential' step that has been long finished ~ 40 minutes ago. Ack – even worse! It literally just finished my build and updated the visualization: the 'parallel sequential' step now shows all steps inside it complete, but all the downstream steps (which were executing earlier, and had shown as complete...) are now gone – not displayed at all. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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] (JENKINS-36155) windows remote slaves don't always come back online
<<< text/html; charset=UTF-8: Unrecognized >>>
[JIRA] [core] (JENKINS-32950) Jenkins slave resets connection during or just after artifacts download.
Title: Message Title boris ivan commented on JENKINS-32950 Re: Jenkins slave resets connection during or just after artifacts download. I have seen the same problem for years. I typically see this at the end of a build when doing a maven site site:deploy. My guess is that something about the rapid transfer of small files to build the resultant website is preventing some sort of keepalive from working, or tripping some kind of integrity check. Same stack trace on windows slave, etc. Always: May 04, 2016 10:17:36 AM hudson.remoting.SynchronousCommandTransport$ReaderThread run SEVERE: I/O error in channel channel java.net.SocketException: Connection reset at java.net.SocketInputStream.read(Unknown Source) at java.net.SocketInputStream.read(Unknown Source) at java.io.BufferedInputStream.fill(Unknown Source) at java.io.BufferedInputStream.read1(Unknown Source) at java.io.BufferedInputStream.read(Unknown Source) ... ... 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] [core] (JENKINS-23862) when viewing console output, way too much screen real estate wasted
Title: Message Title boris ivan commented on JENKINS-23862 Re: when viewing console output, way too much screen real estate wasted Any chance this can get prioritized? The wasted space is killing me. It's causing a majority of lines to wrap that would otherwise not wrap, more difficult to read. 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] [core] (JENKINS-29748) changelog shows no content/changes in 1.623
Title: Message Title boris ivan created an issue Jenkins / JENKINS-29748 changelog shows no content/changes in 1.623 Issue Type: Bug Assignee: Unassigned Components: core Created: 03/Aug/15 1:32 PM Priority: Minor Reporter: boris ivan Hi, Minor issue here – 1.623 shows as a new Jenkins build available, but the changelog shows that nothing changed. I'm sure there is a technical reason why this occurred, but it's something that should be addressed. Add Comment
[JIRA] [core] (JENKINS-29518) 1.621 available, but 1.620 is most recent listed in changelog
Title: Message Title boris ivan commented on JENKINS-29518 Re: 1.621 available, but 1.620 is most recent listed in changelog youch, that sounds even worse (and probably the same problem). I had only noticed the changelog wasn't up even though the new version claimed to be available. I hadn't even tried to upgrade yet. 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] [core] (JENKINS-29518) 1.621 available, but 1.620 is most recent listed in changelog
Title: Message Title boris ivan created an issue Jenkins / JENKINS-29518 1.621 available, but 1.620 is most recent listed in changelog Issue Type: Bug Assignee: Unassigned Components: core Created: 20/Jul/15 5:25 PM Priority: Minor Reporter: boris ivan My Jenkins shows that 1.621 is available for auto-upgrade, but when I examine the changelog there is no reference to 1.621, only 1.620. Add Comment This
[JIRA] [core] (JENKINS-23880) JNLP slave : slave.jar should update itself when Jenkins is updated
Title: Message Title boris ivan commented on JENKINS-23880 Re: JNLP slave : slave.jar should update itself when Jenkins is updated Hi, re: a batch script, is the intended usage for me to launch that from the command line of the build agent(s) at the time that I upgrade the Jenkins master? If so, I would agree that it's slightly more convenient than me pointing a web browser to the master and clicking slave.jar with the intent of saving it locally and then killing/re-running (when I remember to do so). The point of logging this issue isn't that there is no path forward to proceed – it's certainly not a high priority 'bug', I'm sure we're all in agreement. And today, everyone can update their slave.jar file manually (or create a script like the one you proposed), so nobody is 'stuck'. But there are so many aspects of Jenkins that are slick and provide a good user experience, why shouldn't this be one of them? The potentially bad/awkward aspect of not doing this is that (I think) slave.jar can get out of sync to the point where there is a bug – there is no slave-master compatibility version enforcement that I am aware of, _if _the user doesn't remember to upgrade their slave(s) each time. I know there have been multiple Jenkins users that have had that question and the same feeling of (hmm, is the current problem I'm seeing with this slave due to the fact that I didn't upgrade the slave.jar when I upgraded the master, even though slave.jar rarely changes?) Anyway, that's the scoop behind me logging this. The benefit (to me) seems clear, even though we'd probably both be in violent agreement that it's not a P0... 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
[JIRA] [windows-slaves-plugin] (JENKINS-23880) slave.jar should update itself when Jenkins is updated
Title: Message Title boris ivan reopened an issue Thanks for the workaround, but running as a service isn't an option for me. Windows has some very strict security regarding having 'services' writing to mapped drives (Z:, etc), even if you run that service under specific credentials. So, I need to launch the build agent from the command line, which Jenkins supports. I need the slave.jar to upgrade when Jenkins upgrades, in that scenario as well. Jenkins competitors do this successfully, also when launched from the command line (teamcity, etc) Jenkins / JENKINS-23880 slave.jar should update itself when Jenkins is updated Change By: boris ivan Resolution: CannotReproduce Status: Closed Reopened 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
[JIRA] [core] (JENKINS-28456) http://jenkins-ci.org/changelog does not show 1.614, but 1.614 is latest available
Title: Message Title boris ivan created an issue Jenkins / JENKINS-28456 http://jenkins-ci.org/changelog does not show 1.614, but 1.614 is latest available Issue Type: Bug Assignee: Unassigned Components: core Created: 18/May/15 3:24 PM Priority: Minor Reporter: boris ivan 1.614 is the latest available for download, but 1.614 does not show up in the changelog. Logging this bug as minor, since it's not a huge deal. Add Comment
[JIRA] [core] (JENKINS-28013) Archiving artifiacts fails with java.io.IOException: Truncated TAR archive
boris ivan commented on JENKINS-28013 Archiving artifiacts fails with java.io.IOException: Truncated TAR archive Same issue here where build slave is Windows 2012. Artifact only a couple of MB. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [packaging] (JENKINS-27810) attempting to upgrade to 1.608 fails, unable to acquire .war, yet update center connectivity OK
boris ivan created JENKINS-27810 attempting to upgrade to 1.608 fails, unable to acquire .war, yet update center connectivity OK Issue Type: Bug Assignee: Kohsuke Kawaguchi Components: packaging Created: 07/Apr/15 2:26 PM Description: When attempting to upgrade to 1.608 from 1.607, the 'preparation' checks all pass (Checking update center connectivity - Success). But Jenkins.war = pending, and similarly if I try to update a plugin, they are all pending. Not sure what the problem is, but the fact that the connectivity check to update center passes, yet all subsequent actions fail is concerning. I typically update Jenkins with every new build, and haven't seen this before, and when I noticed that there were changes implemented re: 'packaging' a couple of days ago, the timing seems suspect. Please feel free to transfer this to 'core' if it is truly unrelated to 'packaging'.. Environment: Jenkins 1.607, attempting to upgrade to 1.608. Project: Jenkins Priority: Critical Reporter: boris ivan This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [core] (JENKINS-20759) On windows slaves, occasional crash after successful build: Failed to write winp.x64.dll
boris ivan commented on JENKINS-20759 On windows slaves, occasional crash after successful build: Failed to write winp.x64.dll I have not seen this problem for a several weeks now, though admittedly I can't pinpoint which release stopped it. (I tend to upgrade within the week of a release coming out, though I never know when I need to upgrade slave.jar... I upgrade that much less frequently). But the problem happened so frequently before, that it certainly seems to have been addressed. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [build-monitor] (JENKINS-23877) With 1.572, long consoles will not display 'full' console while build is still running, only a portion
boris ivan created JENKINS-23877 With 1.572, long consoles will not display full console while build is still running, only a portion Issue Type: Bug Affects Versions: current Assignee: Praqma Support Components: build-monitor, console-tail, logging Created: 18/Jul/14 3:40 PM Description: Our jenkins jobs yield hundreds of pages of output. New in 1.572, if we look at 'full' console *while the build is in progress*, only a portion is shown, and we get the spinning icon at bottom of console but nothing else comes. Interestingly, when the job is finished, I can click on the 'full' console and it works. It is only during the time that the job is running, that the 'full' console only shows a portion. The portion that it shows is not the latest, either. Specifically, while the job is running, if we click on 'full' console, I'll see the first n pages from the beginning of the build, then it will be stuck. But if we click on 'view console' (NOT the full console), we can see the most recent set of logs (i.e. 'tail'). This problem did not occur in 1.571. Environment: Webserver and build agent on separate Windows 2012 machines. Browsers used: FF and Chrome -- same result. (and did not occur in 1.571) Project: Jenkins Priority: Major Reporter: boris ivan This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [windows-slaves] (JENKINS-23880) slave.jar should update itself when Jenkins is updated
boris ivan created JENKINS-23880 slave.jar should update itself when Jenkins is updated Issue Type: Bug Assignee: Kohsuke Kawaguchi Components: windows-slaves Created: 18/Jul/14 4:25 PM Description: slave.jar should update itself when Jenkins is updated. I have a large qty of remote build agents, and when we see problems, we never know if the outdated slave.jar is relevant or not. This should be changed once and for all so that it detects the change and auto updates itself when the Jenkins server is updated. Competing CI servers have had this as basic functionality for years, it would be great if Jenkins supported the same. Environment: any Project: Jenkins Priority: Major Reporter: boris ivan This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [ui-changes] (JENKINS-23862) when viewing console output, way too much screen real estate wasted
boris ivan created JENKINS-23862 when viewing console output, way too much screen real estate wasted Issue Type: Improvement Affects Versions: current Assignee: Unassigned Attachments: jenkins-console.jpg Components: ui-changes Created: 17/Jul/14 6:33 PM Description: When viewing console output for any build, somewhere between 1/3 - 1/4 of the browser screen is wasted, especially when scrolling down. Specifically, the menu selections on the upper left side of the screen: Back To Project Status Changes Console Output (etc) there is a very large amount of space dedicated to these options. And it gets worse: when we scroll down to review more of the console output, the menu options are gone (scrolled away), but the amount of space dedicated to them still remains. The net effect is that somewhere between 1/3 and 1/4 of the screen (the left hand side) is blank and unused. This looks poor (especially when the menu items aren't even there because we've scrolled down) but is truly a hindrance when trying to review large console outputs. I'd love to see a 'collapse' icon or any other kind of solution that would allow that menu to collapse to a small icon or relocate to the top center of the window or any other solution that ends up not producing empty blank space. It seems that in the most recent release (1.572), the behavior changed somewhat, but it doesn't really fix it. It seems that now if we make the browser window narrower, the menu items will jump to the top and stop indenting the entire left portion of the window. But since this only happens when we narrow the window, this doesn't help us view large console output, since we want to make that window wider in the first place.. Please excuse the ugly blackout scribbling on the attachment. But note all the unused space on the left Environment: any Project: Jenkins Priority: Major Reporter: boris ivan This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [ssh] (JENKINS-22938) SSH slave connections die after the slave outputs 4MB of stderr, usually during findbugs analysis
boris ivan commented on JENKINS-22938 SSH slave connections die after the slave outputs 4MB of stderr, usually during findbugs analysis Regarding the "== Why someone would have 4MB of stderr output ==" Many of us use Jenkins for things like running Maven builds which have a goal of "integration-test". In other words, there is very little 'build' in the traditional sense, but instead reams and reams of output from testNG tests, etc, and there might be a valid reason to use stderr. Couple that with potentially thousands of tests... Just adding this commentary in case it helps people think of scenarios like this. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [ssh] (JENKINS-22938) SSH slave connections die after the slave outputs 4MB of stderr, usually during findbugs analysis
boris ivan edited a comment on JENKINS-22938 SSH slave connections die after the slave outputs 4MB of stderr, usually during findbugs analysis Regarding the "== Why someone would have 4MB of stderr output ==" Some of us use Jenkins for things like running Maven builds which have a goal of "integration-test". In other words, there is very little 'build' in the traditional sense, and in fact the 'build' itself may not even be unit tests associated with a build of a product-under-test, but an entirely separate test project being built that interacts with something completely external. This generates reams and reams of output from testNG tests, etc, and there might be a valid reason to use stderr in some of that output. Couple that with potentially thousands of tests... Just adding this commentary in case it helps people think of scenarios like this. We use it in this fashion nightly. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [core] (JENKINS-21913) java.io.StreamCorruptedException: invalid type code: 41 occured at end of build.
boris ivan commented on JENKINS-21913 java.io.StreamCorruptedException: invalid type code: 41 occured at end of build. Occurred again today with build 1.553. Interestingly, while I see the same stack trace later in the build as described above, I do notice some odd output slightly earlier than the stack trace. The Maven goals this is executing are: integration-test site site:deploy When executing the maven goal "site", it generates javadocs and a few other standard reports. It looks like it is progressing along, and then I see the following strange output below: 08:35:17 Constructing Javadoc information... 08:35:17 Standard Doclet version 1.7.0_40 08:35:17 Building tree for all the packages and classes... ... ... 08:35:17 200 warnings 08:35:17 WARNING Javadoc Warnings 08:35:17 WARNING C:\Jenkins\workspace[redacted].java:27: warning - @count is an unknown tag. 08:35:17 WARNING C:\Jenkins\workspace[redacted].java:27: warning - @volname is an unknown tag. 08:35:17 WARNING C:\Jenkins\workspace[redacted].java:80: warning - @return tag has no arguments. 08:35:17 [8mha:Yx+LCP9b85aBtbiIQSWjNKU4P0+vJLE4u1gvPjexLDVPzxdEhicW5WXmpfvll6S2fNly5fzGzauYGBgqihikoFqS8/OK83NS9ZwhNEghAwQwghQWAACwxA+XYg== [0mWARNING C:\Jenkins\workspace[redacted].java:80: warning - @param argument "hostIP" is not a parameter name. Note the garbage above "8mha:Yx+LCAAA..." Next, the site is deployed to an external web server (site:deploy). After this, the 'maven' portion of the build is complete, and the email-ext plugin would normally fire. But this is what I see instead: 08:36:56 ERROR: Failed to parse POMs 08:36:56 hudson.remoting.ChannelClosedException: channel is already closed 08:36:56 at hudson.remoting.Channel.send(Channel.java:524) 08:36:56 at hudson.remoting.Request.call(Request.java:129) 08:36:56 at hudson.remoting.Channel.call(Channel.java:722) 08:36:56 at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:167) 08:36:56 at com.sun.proxy.$Proxy74.isAlive(Unknown Source) 08:36:56 at hudson.Launcher$RemoteLauncher$ProcImpl.isAlive(Launcher.java:930) 08:36:56 at hudson.maven.ProcessCache$MavenProcess.call(ProcessCache.java:165) 08:36:56 at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:833) 08:36:56 at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:585) 08:36:56 at hudson.model.Run.execute(Run.java:1676) 08:36:56 at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:519) 08:36:56 at hudson.model.ResourceController.execute(ResourceController.java:88) 08:36:56 at hudson.model.Executor.run(Executor.java:231) 08:36:56 Caused by: hudson.remoting.DiagnosedStreamCorruptionException 08:36:56 Read back: 'o' 08:36:56 Read ahead: 'redacted.html#108"108/a/td/tr' 0x0d 0x0a 08:36:56 'tr class="b"' 0x0d 0x0a 08:36:56 'tdimg alt="Errors" src="" //td' 0x0d 0x0a 08:36:56 'tdLine is longer than 80 characters (found 82)./td' 0x0d 0x0a Note the last line above. "Line is longer than 80 characters". That is something specific to the checkstyle reports, during the Maven "site" goal (I think). Hmm. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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/groups/opt_out.
[JIRA] [core] (JENKINS-22024) Windows services shows Jenkins as not running.. but it is.
boris ivan created JENKINS-22024 Windows services shows Jenkins as not running.. but it is. Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: core Created: 03/Mar/14 8:47 PM Description: My Jenkins webserver is running on a Windows 2012 VM. It's been working fine and is still running fine after upgrading from 1.552 to 1.553. But after upgrading to 1.553, the 'services' tool in Windows tells me that Jenkins is not running. But it is running it's running fine. I can refresh webpages, launch jobs, etc, from web browsers. But for the "Jenkins" service, the status is blank, where normally it would say: "running". I've closed the tool and relaunched it, hit F5 to refresh, etc. Jenkins is working fine, but the service tool from Microsoft doesn't say it's running. This worked in 1.552. Environment: Windows 2012, Jenkins 1.553, Java 1.7.0-45 Project: Jenkins Priority: Major Reporter: boris ivan This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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/groups/opt_out.
[JIRA] [core] (JENKINS-21913) java.io.StreamCorruptedException: invalid type code: 41 occured at end of build.
boris ivan created JENKINS-21913 java.io.StreamCorruptedException: invalid type code: 41 occured at end of build. Issue Type: Bug Assignee: Unassigned Components: core Created: 21/Feb/14 3:06 PM Description: Executing a Maven build with goal integration-test site site:deploy. Everything goes as planned, and the website is published. At this point the email-ext plugin would typically fire. But here is the output: An attempt to send an e-mail to empty list of recipients, ignored. ERROR: Failed to parse POMs hudson.remoting.ChannelClosedException: channel is already closed at hudson.remoting.Channel.send(Channel.java:524) at hudson.remoting.Request.call(Request.java:129) at hudson.remoting.Channel.call(Channel.java:722) at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:167) at com.sun.proxy.$Proxy55.isAlive(Unknown Source) at hudson.Launcher$RemoteLauncher$ProcImpl.isAlive(Launcher.java:930) at hudson.maven.ProcessCache$MavenProcess.call(ProcessCache.java:165) at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:833) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:565) at hudson.model.Run.execute(Run.java:1670) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:519) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) Caused by: hudson.remoting.DiagnosedStreamCorruptionException At this point there is a lot of debug output from Jenkins of various buffers, etc. Unfortunately tons of proprietary info in those buffers so I'm not going to post here, though I could probably answer specific questions if it's essential. The first set of messages are: Read back: 'A' Read ahead: '[Ljava.lang.Object;@28170a64]' 0x0d 0x0a Later after a few pages of debug output, we see more of the stack, which seems fairly interesting.. at hudson.remoting.FlightRecorderInputStream.analyzeCrash(FlightRecorderInputStream.java:71) at hudson.remoting.ClassicCommandTransport.diagnoseStreamCorruption(ClassicCommandTransport.java:94) at hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:78) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) Caused by: java.io.StreamCorruptedException: invalid type code: 41 at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) at hudson.remoting.Command.readFrom(Command.java:92) at hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:71) ... 1 more Environment: Server and Remote Build Agent Windows 2012. Maven build. Project: Jenkins Priority: Critical Reporter: boris ivan This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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/groups/opt_out.
[JIRA] [core] (JENKINS-21913) java.io.StreamCorruptedException: invalid type code: 41 occured at end of build.
boris ivan updated JENKINS-21913 java.io.StreamCorruptedException: invalid type code: 41 occured at end of build. Change By: boris ivan (21/Feb/14 3:10 PM) Environment: ServerandRemoteBuildAgentWindows2012.Mavenbuild. Jenkins1.551 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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/groups/opt_out.
[JIRA] [core] (JENKINS-21913) java.io.StreamCorruptedException: invalid type code: 41 occured at end of build.
boris ivan commented on JENKINS-21913 java.io.StreamCorruptedException: invalid type code: 41 occured at end of build. I run the build agent (remote: Windows 2012) from the command line. On that window, I see the following stack trace corresponding to the same time as the problem: Feb 21, 2014 7:34:08 AM hudson.remoting.SynchronousCommandTransport$ReaderThread run SEVERE: I/O error in channel channel java.io.IOException: Unexpected termination of the channel at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50) Caused by: java.io.EOFException at java.io.ObjectInputStream$BlockDataInputStream.peekByte(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) at hudson.remoting.Command.readFrom(Command.java:92) at hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:71) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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/groups/opt_out.
[JIRA] [core] (JENKINS-20630) Jenkins fails to start
boris ivan commented on JENKINS-20630 Jenkins fails to start Hi Kohsuke, Jenkins-ci.org says that the latest release is 1.542, but the changelog for 'upcoming changes' for 1.542 shows 4 bug fixes, none of which are 20630. Can you confirm that this fix is in? If so, should it be in the changelog list? Thanks in advance. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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/groups/opt_out.
[JIRA] [core] (JENKINS-20630) Jenkins fails to start
boris ivan commented on JENKINS-20630 Jenkins fails to start Does anyone use Windows and not see this problem? I can't make the problem go away regardless what version of Windows/Java we use. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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/groups/opt_out.
[JIRA] [all-changes] (JENKINS-20759) On windows slaves, occasional crash after successful build: Failed to write winp.x64.dll
boris ivan created JENKINS-20759 On windows slaves, occasional crash after successful build: Failed to write winp.x64.dll Issue Type: Bug Affects Versions: current Assignee: wolfs Components: all-changes Created: 25/Nov/13 9:21 PM Description: Occasionally, remote windows slaves die with the following trace spit to the screen on the remote slave (I am running via command line, not as a service): Nov 20, 2013 4:16:10 PM org.jvnet.winp.Native load WARNING: Failed to write winp.x64.dll java.io.FileNotFoundException: C:\Users\redacted\.jenkins\cache\jars\01\winp.x64.dll (The process can not access the file because it is being used by another process) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:212) at java.io.FileOutputStream.init(FileOutputStream.java:165) at org.jvnet.winp.Native.load(Native.java:81) at org.jvnet.winp.Native.clinit(Native.java:52) at org.jvnet.winp.WinProcess.enableDebugPrivilege(WinProcess.java:200) at hudson.util.ProcessTree$Windows.clinit(ProcessTree.java:477) at hudson.util.ProcessTree.get(ProcessTree.java:336) at hudson.Launcher$RemoteLauncher$KillTask.call(Launcher.java:899) at hudson.Launcher$RemoteLauncher$KillTask.call(Launcher.java:890) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at hudson.remoting.Engine$1$1.run(Engine.java:63) at java.lang.Thread.run(Thread.java:724) # A fatal error has been detected by the Java Runtime Environment: # EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x0c8b3a90, pid=7136, tid=2024 # JRE version: 7.0_25-b17 Java VM: Java HotSpot(TM) 64-Bit Server VM (23.25-b01 mixed mode windows-amd64 compressed oops) Problematic frame: C 0x0c8b3a90 # Core dump written. Default location: C:hs_err_pid7136.mdmp # An error report file with more information is saved as: C:hs_err_pid7136.log When this occurs, here's the trailing end of the build console for this build: ... ... INFO BUILD SUCCESS INFO INFO Total time: 1:33.420s INFO Finished at: Wed Nov 20 16:16:09 EST 2013 INFO Final Memory: 42M/272M INFO JENKINS Archiving C:\jenkins\workspace\redacted\pom.xml to redactedSNAPSHOT.pom JENKINS Archiving C:\jenkins\workspace\redacted-SNAPSHOT.jar to redactedjar channel stopped FATAL: hudson.remoting.RequestAbortedException: java.net.SocketException: Connection reset hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.net.SocketException: Connection reset at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:41) at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:34) at hudson.remoting.Request.call(Request.java:174) at hudson.remoting.Channel.call(Channel.java:714) at hudson.Launcher$RemoteLauncher.kill(Launcher.java:887) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:585) at hudson.model.Run.execute(Run.java:1679) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:509) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:230) Caused by:
[JIRA] [all-changes] (JENKINS-20759) On windows slaves, occasional crash after successful build: Failed to write winp.x64.dll
boris ivan
updated JENKINS-20759
On windows slaves, occasional crash after successful build: Failed to write winp.x64.dll
Change By:
boris ivan
(25/Nov/13 9:29 PM)
Description:
Occasionally,remotewindowsslavesdiewiththefollowingtracespittothescreenontheremoteslave(Iamrunningviacommandline,notasaservice):
{noformat}
Nov20,20134:16:10PMorg.jvnet.winp.NativeloadWARNING:Failedtowritewinp.x64.dlljava.io.FileNotFoundException:C:\Users\redacted\.jenkins\cache\jars\01\winp.x64.dll(Theprocesscannotaccessthefilebecauseitisbeingusedbyanotherprocess)atjava.io.FileOutputStream.open(NativeMethod)atjava.io.FileOutputStream.init(FileOutputStream.java:212)atjava.io.FileOutputStream.init(FileOutputStream.java:165)atorg.jvnet.winp.Native.load(Native.java:81)atorg.jvnet.winp.Native.clinit(Native.java:52)atorg.jvnet.winp.WinProcess.enableDebugPrivilege(WinProcess.java:200)athudson.util.ProcessTree$Windows.clinit(ProcessTree.java:477)athudson.util.ProcessTree.get(ProcessTree.java:336)athudson.Launcher$RemoteLauncher$KillTask.call(Launcher.java:899)athudson.Launcher$RemoteLauncher$KillTask.call(Launcher.java:890)athudson.remoting.UserRequest.perform(UserRequest.java:118)athudson.remoting.UserRequest.perform(UserRequest.java:48)athudson.remoting.Request$2.run(Request.java:326)athudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)atjava.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)atjava.util.concurrent.FutureTask.run(FutureTask.java:166)atjava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)atjava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)athudson.remoting.Engine$1$1.run(Engine.java:63)atjava.lang.Thread.run(Thread.java:724)##AfatalerrorhasbeendetectedbytheJavaRuntimeEnvironment:##EXCEPTION_ACCESS_VIOLATION(0xc005)atpc=0x0c8b3a90,pid=7136,tid=2024##JREversion:7.0_25-b17#JavaVM:JavaHotSpot(TM)64-BitServerVM(23.25-b01mixedmodewindows-amd64compressedoops)#Problematicframe:#C0x0c8b3a90##Coredumpwritten.Defaultlocation:C:\\hs_err_pid7136.mdmp##Anerrorreportfilewithmoreinformationissavedas:#C:\\hs_err_pid7136.log
{noformat}
Whenthisoccurs,heresthetrailingendofthebuildconsoleforthisbuild:
{noformat}
..[INFO]BUILDSUCCESS[INFO][INFO]Totaltime:1:33.420s[INFO]Finishedat:WedNov2016:16:09EST2013[INFO]FinalMemory:42M/272M[INFO][JENKINS]ArchivingC:\jenkins\workspace\redacted\pom.xmltoredactedSNAPSHOT.pom[JENKINS]ArchivingC:\jenkins\workspace\redacted-SNAPSHOT.jartoredactedjarchannelstoppedFATAL:hudson.remoting.RequestAbortedException:java.net.SocketException:Connectionresethudson.remoting.RequestAbortedException:hudson.remoting.RequestAbortedException:java.net.SocketException:Connectionreset athudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:41) athudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:34) athudson.remoting.Request.call(Request.java:174) athudson.remoting.Channel.call(Channel.java:714) athudson.Launcher$RemoteLauncher.kill(Launcher.java:887) athudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:585) athudson.model.Run.execute(Run.java:1679) athudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:509) athudson.model.ResourceController.execute(ResourceController.java:88) athudson.model.Executor.run(Executor.java:230)Causedby:hudson.remoting.RequestAbortedException:java.net.SocketException:Connectionreset athudson.remoting.Request.abort(Request.java:299) athudson.remoting.Channel.terminate(Channel.java:774) athudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:69)Causedby:java.net.SocketException:Connectionreset atjava.net.SocketInputStream.read(UnknownSource) atjava.net.SocketInputStream.read(UnknownSource) atjava.io.BufferedInputStream.fill(UnknownSource) atjava.io.BufferedInputStream.read(UnknownSource) athudson.remoting.FlightRecorderInputStream.read(FlightRecorderInputStream.java:77)
[JIRA] [all-changes] (JENKINS-20759) On windows slaves, occasional crash after successful build: Failed to write winp.x64.dll
boris ivan updated JENKINS-20759 On windows slaves, occasional crash after successful build: Failed to write winp.x64.dll crashdump log file Change By: boris ivan (25/Nov/13 9:33 PM) Attachment: hs_err_pid7136.txt This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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/groups/opt_out.
[JIRA] [core] (JENKINS-20630) Jenkins fails to start
boris ivan commented on JENKINS-20630 Jenkins fails to start I think this is simple: 1) This release should be pulled. 2) Some kind of automated test (if only there was some kind of software package that could run integration tests after a software build, on a continuous basis) should be in place to load the nightly builds on each major OS and if they fail, then take action (back out submit, flag for review and don't release to public, any number of potential actions here) 3) Regarding a warning on the front page.. I disagree. Not because I feel that the people suggesting this are wrong, but it promotes bad behavior/poor code. The Jenkins community responsible for the stability of the product should take steps to reduce the possibility of a bugs like this making it to release-phase, instead of saying "meh, these things happen!". This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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/groups/opt_out.
