[JIRA] (JENKINS-49763) Duration time is incorrect in a parallel pipeline step.
Title: Message Title Ben Walding commented on JENKINS-49763 Re: Duration time is incorrect in a parallel pipeline step. Note: my example doesn't show negatives, but does show the blueocean endpoint returning invalid timings for parallel stages, and not accumulating the time for the overall stage correctly. I suspect they're all issues in a similar section of code, so will leave my notes here. 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.188710.1519731897000.2014.1557805440129%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-49763) Duration time is incorrect in a parallel pipeline step.
Title: Message Title
Ben Walding commented on JENKINS-49763
Re: Duration time is incorrect in a parallel pipeline step.
I've reproduced this using a similar pipeline in declarative format. Classic Stages ViewBlueOcean ViewPipeline
Jenkinsfile
pipeline {
agent {
label "docker"
}
stages {
stage('Step Serial') {
steps {
sh "sleep 5"
}
}
stage('Step Parallel') {
parallel {
stage("Primary Branch") {
steps {
sh "sleep 4"
}
}
stage("Secondary Branch") {
steps {
sh "sleep 6"
}
}
}
}
}
}
REST Response /blue/rest/organizations/jenkins/pipelines/test-timings/runs/3/nodes/?limit=1
REST Response
[
{
"_class": "io.jenkins.blueocean.rest.impl.pipeline.PipelineNodeImpl",
"_links": {
"self": {
"_class": "io.jenkins.blueocean.rest.hal.Link",
"href": "/blue/rest/organizations/jenkins/pipelines/test-timings/runs/3/nodes/6/"
},
"actions": {
"_class": "io.jenkins.blueocean.rest.hal.Link",
"href": "/blue/rest/organizations/jenkins/pipelines/test-timings/runs/3/nodes/6/actions/"
},
"steps": {
"_class": "io.jenkins.blueocean.rest.hal.Link",
"href": "/blue/rest/organizations/jenkins/pipelines/test-timings/runs/3/nodes/6/steps/"
}
},
"actions": [],
"displayDescription": null,
"displayName": "Step Serial",
"durationInMillis": 5573,
"id": "6",
"input": null,
"result": "SUCCESS",
"startTime": "2019-05-14T03:31:27.174+",
"state": "FINISHED",
"type": "STAGE",
"causeOfBlockage": null,
"edges": [
{
"_class": "io.jenkins.blueocean.rest.impl.pipeline.PipelineNodeImpl$EdgeImpl",
"id": "11",
"type": "STAGE"
}
],
"firstParent": null,
"restartable": true
},
{
"_class": "io.jenkins.blueocean.rest.impl.pipeline.PipelineNodeImpl",
"_links": {
"self": {
"_class": "io.jenkins.blueocean.rest.hal.Link",
"href": "/blue/rest/organizations/jenkins/pipelines/test-timings/runs/3/nodes/11/"
},
"actions": {
"_class": "io.jenkins.blueocean.rest.hal.Link",
"href": "/blue/rest/organizations/jenkins/pipelines/test-timings/runs/3/nodes/11/actions/"
},
"steps": {
"_class": "io.jenkins.blueocean.rest.hal.Link",
"href": "/blue/rest/organizations/jenkins/pipelines/test-timings/runs/3/nodes/11/steps/"
}
},
"actions": [],
"displayDescription": null,
"displayName": "Step Parallel",
"durationInMillis": 31,
"id":
[JIRA] (JENKINS-49763) Duration time is incorrect in a parallel pipeline step.
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-49763 Duration time is incorrect in a parallel pipeline step. Change By: Ben Walding Attachment: screenshot-1.png 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.188710.1519731897000.2008.1557805200228%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-49763) Duration time is incorrect in a parallel pipeline step.
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-49763 Duration time is incorrect in a parallel pipeline step. Change By: Ben Walding Attachment: Screen Shot 2019-05-14 at 1.37.24 pm.png 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.188710.1519731897000.2005.1557805080171%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-28010) Use Google Apps group for Authorization
Title: Message Title Ben Walding commented on JENKINS-28010 Re: Use Google Apps group for Authorization Ryan Campbell - in regards your pondering of Org Unit vs. Groups - my feeling is that mapping groups from GSuite to Jenkins makes the most sense. Org Units are much more limiting since a user only exists in a single Org Unit (although OUs are hierarchical). If you look at how GCP (Google Cloud) works, they let you assign groups directly into the permissions lists - so I can have engineering-tea...@example.com as a group with permissions on a given project etc. The Google API for managing / querying users as groups is solid and well-documented - happy to discuss when you're available - you know where I am! Christopher Orr - in regards your question about the API - the API is a bit finicky to setup initially. You have two options for calling the API a service account with appropriate scopes / permissions assigned a set of OAuth tokens for the "Jenkins" (or app), those token can then be used to issue an OAuth request (with required scopes) - which is basically a URL that a human will click on to generate a token. That token is then used by the Jenkins / app to issue directory HTTP requests. The guidance from Google is that you can't use hard-coded tokens in OSS products (so Jenkins can't have a set burned in) - my gut feeling is that the most expedient way for Jenkins to work would be for end-users to create service accounts (this is not a GSuite user, but essentially a set of tokens) with the correct scopes. The service account credentials would then be entered into Jenkins as another pair of credential fields. This guide is the one I used - https://developers.google.com/admin-sdk/directory/v1/quickstart/go (There are Java versions of the same thing if that's more your style). The example uses the "app" style token setup (rather than service account style setup) Add Comment This message was sent by
[JIRA] (JENKINS-42994) In some situations, the 're-run' button will not trigger a build and not give any feedback of failure.
Title: Message Title Ben Walding commented on JENKINS-42994 Re: In some situations, the 're-run' button will not trigger a build and not give any feedback of failure. My case is for the "Run" button rather than the "Re-run" Also - that Jenkinsfile trace is referring to an internal CloudBees script that it shouldn't have access to (not a security risk, but I think the error is a valid error). I have had issues in the past with Re-run - but that was before parameters were supported - and the lack of parameters in the re-run was the root cause of the problem. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-43148) Developer can load and save pipelines from the editor using native git
Title: Message Title Ben Walding commented on JENKINS-43148 Re: Developer can load and save pipelines from the editor using native git If you are willing to create something "different" for Github, then there is a Content API that will let manipulate files without having a checkout - https://developer.github.com/v3/repos/contents/ Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-43203) Branch filtering dropdown unsorted
Title: Message Title Ben Walding created an issue Jenkins / JENKINS-43203 Branch filtering dropdown unsorted Issue Type: Improvement Assignee: Unassigned Attachments: image-2017-03-30-11-27-30-081.png Components: blueocean-plugin Created: 2017/Mar/30 1:29 AM Priority: Trivial Reporter: Ben Walding The filter list is unsorted (or is sorted by some weird ordering that I can't discern!) I would have expected an order of master assume-role iterate PR-1 PR-2 or assume-role iterate master PR-1 PR-2
[JIRA] (JENKINS-43117) Run declarative pipeline job with parameters fails if description is null
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-43117 Run declarative pipeline job with parameters fails if description is null Change By: Ben Walding Issue Type: Improvement Bug Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-43117) Run declarative pipeline job with parameters fails if description is null
Title: Message Title Ben Walding created an issue Jenkins / JENKINS-43117 Run declarative pipeline job with parameters fails if description is null Issue Type: Improvement Assignee: Unassigned Attachments: image-2017-03-27-11-27-49-492.png Components: blueocean-plugin Created: 2017/Mar/27 1:30 AM Environment: ci.blueocean.io Priority: Minor Reporter: Ben Walding If a parameter is configured via declarative pipeline, an no description is set, it will cause the "Run job" button "not work at all" inside blueocean.Console stack trace blueocean.js:7226 Uncaught Error: Invalid arg type for "markupText". Must be a string. at removeMarkupTags (blueocean.js:7226) at String.render (blueocean.js:4316) at ReactCompositeComponentWrapper._renderValidatedComponentWithoutOwnerOrContext (blueocean.js:84749) at ReactCompositeComponentWrapper._renderValidatedComponent (blueocean.js:84772) at ReactCompositeComponentWrapper.performInitialMount (blueocean.js:84314) at ReactCompositeComponentWrapper.mountComponent (blueocean.js:84210) at Object.mountComponent (blueocean.js:91223) Example Job See - https://ci.blueocean.io/blue/organizations/jenkins/scratch%2Fbwalding%2Ftest-parameter/
[JIRA] (JENKINS-43117) Run declarative pipeline job with parameters fails if description is null
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-43117 Run declarative pipeline job with parameters fails if description is null Change By: Ben Walding Environment: ci.blueocean.io + 1.0-rc2 Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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-43117) Run declarative pipeline job with parameters fails if description is null
Title: Message Title
Ben Walding updated an issue
Jenkins / JENKINS-43117
Run declarative pipeline job with parameters fails if description is null
Change By:
Ben Walding
If a parameter is configured via declarative pipeline, an and no description is set, it will cause the "Run job" button "not work at all" inside blueocean. !image-2017-03-27-11-27-49-492.png|thumbnail! h4. Console stack trace{noformat}blueocean.js:7226 Uncaught Error: Invalid arg type for "markupText". Must be a string.at removeMarkupTags (blueocean.js:7226)at String.render (blueocean.js:4316)at ReactCompositeComponentWrapper._renderValidatedComponentWithoutOwnerOrContext (blueocean.js:84749)at ReactCompositeComponentWrapper._renderValidatedComponent (blueocean.js:84772)at ReactCompositeComponentWrapper.performInitialMount (blueocean.js:84314)at ReactCompositeComponentWrapper.mountComponent (blueocean.js:84210)at Object.mountComponent (blueocean.js:91223){noformat}h4. Example JobSee - https://ci.blueocean.io/blue/organizations/jenkins/scratch%2Fbwalding%2Ftest-parameter/{noformat}pipeline { agent any parameters {// Note the lack of descriptionstring(name: 'PERSON', defaultValue: 'Mr Jenkins') } stages {stage('Example') { steps {echo "Hello ${params.PERSON}" }} }}{noformat}
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
[JIRA] (JENKINS-42828) Stage log title loses context in parallel build
Title: Message Title Ben Walding created an issue Jenkins / JENKINS-42828 Stage log title loses context in parallel build Issue Type: Improvement Assignee: Unassigned Attachments: image-2017-03-16-15-07-12-938.png, image-2017-03-16-15-08-02-789.png, image-2017-03-16-15-08-23-469.png Components: blueocean-plugin Created: 2017/Mar/16 5:10 AM Priority: Minor Reporter: Ben Walding When you're on a normal build step (and watching it run) - the title for the log is "Step - $STAGE", but when you are on a parallel build step - you are told "Step - $PARALLELNAME" I would argue, not very convincingly The log title should be "Step - $STAGE - $PARALLELNAME" - as I have multiple stages with the same parallel names (architecture in this case). Current display Expected display Complete Pipeline Add Comment
[JIRA] (JENKINS-42425) "configure" button incorrectly assumes a servlet context of "/jenkins"
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-42425 "configure" button incorrectly assumes a servlet context of "/jenkins" Change By: Ben Walding The "gear" icon / "configure" icon on a Job should take me to the Jenkins classic configuration page for the job.It currently takes me to a broken URL in Jenkins classic as it assumes a "/jenkins/" prefixh4. Steps1. I am viewing "/blue/organizations/jenkins/pumpkin/activity"2. I click on the "gear" icon (left hand side, next to favourite star) - check all gear icons - as they're "all" doing 3. I am taken to /jenkins/job/pumpkin/configureh4. Expected1. I should have been taken to /job/pumpkin/configure Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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] (JENKINS-42425) "configure" button incorrectly assumes a servlet context of "/jenkins"
Title: Message Title Ben Walding created an issue Jenkins / JENKINS-42425 "configure" button incorrectly assumes a servlet context of "/jenkins" Issue Type: Bug Assignee: Unassigned Components: blueocean-plugin Created: 2017/Mar/02 12:45 AM Environment: b24 Priority: Minor Reporter: Ben Walding The "gear" icon / "configure" icon on a Job should take me to the Jenkins classic configuration page for the job. It currently takes me to a broken URL in Jenkins classic as it assumes a "/jenkins/" prefix Steps 1. I am viewing "/blue/organizations/jenkins/pumpkin/activity" 2. I click on the "gear" icon (left hand side, next to favourite star) 3. I am taken to /jenkins/job/pumpkin/configure Expected 1. I should have been taken to /job/pumpkin/configure Add Comment
[JIRA] (JENKINS-42293) "Open Blue Ocean" opens links to incorrect URL in some cases resulting in 404
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-42293 "Open Blue Ocean" opens links to incorrect URL in some cases resulting in 404 Change By: Ben Walding *Scope*If we don't know where to send someone we should send them to the dashboard in BlueFor example: from the /pluginManager / JENKINS-42301 seems to be a duplicate but would be good to check on completion *To reproduce*1. Browse to the plugin manager (/pluginManager/)2. Click on "Open Blue Ocean"3. End up on a 404 at /pluginManager/blueThis occurs for admin links that have a trailing slash (/pluginManager/, /updateCentre/ are two - but this is not an exhaustive list. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-42293) "Open Blue Ocean" opens links to incorrect URL if source link has trailing slash or more than 1 path component
Title: Message Title Ben Walding created an issue Jenkins / JENKINS-42293 "Open Blue Ocean" opens links to incorrect URL if source link has trailing slash or more than 1 path component Issue Type: Bug Assignee: Unassigned Components: blueocean-plugin Created: 2017/Feb/24 1:13 AM Environment: b24 Priority: Minor Reporter: Ben Walding 1. Browse to the plugin manager (/pluginManager/) 2. Click on "Open Blue Ocean" 3. End up on a 404 at /pluginManager/blue This occurs for admin links that have a trailing slash (/pluginManager/, /updateCentre/ are two - but this is not an exhaustive list. Add Comment
[JIRA] (JENKINS-42137) Keep an eye on SSE events and resulting REST API calls
Title: Message Title Ben Walding commented on JENKINS-42137 Re: Keep an eye on SSE events and resulting REST API calls I flagged this because in a small instance - you will barely notice it. But it is making one request per running job every cycle (30s) - so on a big instance this might start to be a real issue - e.g. 30 concurrent jobs - with 30 users - that would be 1800 requests/min (on top of regular workload) (I don't have to worry about how to solve it!) Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-42137) REGRESSION: A lot of unnecessary requests for pipeline run details and events
Title: Message Title
Ben Walding updated an issue
Jenkins / JENKINS-42137
REGRESSION: A lot of unnecessary requests for pipeline run details and events
Change By:
Ben Walding
The BlueOcean main pipeline screen (https://ci.blueocean.io/blue/pipelines) has an event/websocket thing that is connected appears to the Jenkins server be receiving events for running pipelines that are not visible, and then fetching data, creating more than expected traffic .On a regular basis this sends event from the backend to the frontend detailing things that are running. h4. To reproduce* Open /blue/pipelines/ in one tab* Run a job like bwalding-alwaysBlue from a classic screen in another tab* Note that /blue/pipelines/ receives events for this job and does requests. h4. Some details Event socket:https://ci.blueocean.io/sse-gateway/listen/jenkins-blueocean-core-js-1487311928759-80shtgg3w8q5hpelba9k9Event data:{noformat}open {"dispatcherId":"jenkins-blueocean-core-js-1487311928759-80shtgg3w8q5hpelba9k9","dispatcherInst":1238701885} 16:15:00.445job {"jenkins_object_type":"org.jenkinsci.plugins.workflow.job.WorkflowRun","jenkins_event_uuid":"6c1358f1-f887-41bb-beb9-3228dda99df8","sse_subs_dispatcher_inst":"1238701885","job_run_status":"SUCCESS","job_name":"scratch/bwalding-alwaysBlue","jenkins_org":"jenkins","job_run_queueId":"5246","jenkins_object_name":"#2","blueocean_job_rest_url":"/blue/rest/organizations/jenkins/pipelines/scratch/pipelines/bwalding-alwaysBlue/","jenkins_object_id":"2","jenkins_event":"job_run_ended","sse_subs_dispatcher":"jenkins-blueocean-core-js-1487311928759-80shtgg3w8q5hpelba9k9","blueocean_job_pipeline_name":"scratch/bwalding-alwaysBlue","jenkins_object_url":"job/scratch/job/bwalding-alwaysBlue/2/","jenkins_channel":"job"} {noformat}Once the frontend receives those events, the frontend then makes a call to retrieve details about the run.https://ci.blueocean.io/blue/rest/organizations/jenkins/pipelines/scratch/pipelines/bwalding-alwaysBlue/runs/2/However the important thing to note is that the bwalding-alwaysBlue job is not visible on the front screen - so the frontend is querying the backend for details on jobs that will not change the state of the front end (afaik)In a large instance that is running a lot of jobs all the time, this could be problematic.
[JIRA] (JENKINS-42137) REGRESSION: A lot of unnecessary requests for pipeline run details and events
Title: Message Title
Ben Walding updated an issue
Jenkins / JENKINS-42137
REGRESSION: A lot of unnecessary requests for pipeline run details and events
Change By:
Ben Walding
The BlueOcean main pipeline screen (https://ci.blueocean.io/blue/pipelines) appears to be receiving events for running pipelines has an event/websocket thing that are not visible, and then fetching data, creating more than expected traffic is connected to the Jenkins server . On a regular basis this sends event from the backend to the frontend detailing things that are running. To reproduce Event socket :* Open /blue/pipelines/ in one tab* Run a job like bwalding-alwaysBlue from a classic screen in another tab* Note that /blue/pipelines/ receives events for this job and does requests. So: * Events shouldn't realy arrive as there was nothing subscribing to that pipeline run right? * Fetching data about this uninteresting event also seems wrong.Some details: (I hope the 80shtgg3w8q5hpelba9k9 ID isn't something important https://ci.blueocean.io/sse-gateway/listen/jenkins-blueocean-core-js-1487311928759-80shtgg3w8q5hpelba9k9 Event data: {noformat}open {"dispatcherId":"jenkins-blueocean-core-js-1487311928759-80shtgg3w8q5hpelba9k9","dispatcherInst":1238701885} 16:15:00.445job {"jenkins_object_type":"org.jenkinsci.plugins.workflow.job.WorkflowRun","jenkins_event_uuid":"6c1358f1-f887-41bb-beb9-3228dda99df8","sse_subs_dispatcher_inst":"1238701885","job_run_status":"SUCCESS","job_name":"scratch/bwalding-alwaysBlue","jenkins_org":"jenkins","job_run_queueId":"5246","jenkins_object_name":"#2","blueocean_job_rest_url":"/blue/rest/organizations/jenkins/pipelines/scratch/pipelines/bwalding-alwaysBlue/","jenkins_object_id":"2","jenkins_event":"job_run_ended","sse_subs_dispatcher":"jenkins-blueocean-core-js-1487311928759-80shtgg3w8q5hpelba9k9","blueocean_job_pipeline_name":"scratch/bwalding-alwaysBlue","jenkins_object_url":"job/scratch/job/bwalding-alwaysBlue/2/","jenkins_channel":"job"} {noformat}Once the frontend receives those events, the frontend then makes a call to retrieve details about the run.https://ci.blueocean.io/blue/rest/organizations/jenkins/pipelines/scratch/pipelines/bwalding-alwaysBlue/runs/2/However the important thing to note is that the bwalding-alwaysBlue job is not visible on the front screen - so the frontend is querying the backend for details on jobs that will not change the state of the front end (afaik) In a large instance that is running a lot of jobs all the time, this could be problematic.
[JIRA] (JENKINS-42137) BlueOcean making unnecessary requests for pipeline run details
Title: Message Title
Ben Walding updated an issue
Jenkins / JENKINS-42137
BlueOcean making unnecessary requests for pipeline run details
Change By:
Ben Walding
The BlueOcean main pipeline screen (https://ci.blueocean.io/blue/pipelines) has an event websocket thing that is connect to the Jenkins server.On a regular basis this sends event from the backend to the frontend detailing things that are running.(I hope the 80shtgg3w8q5hpelba9k9 ID isn't something importanthttps://ci.blueocean.io/sse-gateway/listen/jenkins-blueocean-core-js-1487311928759-80shtgg3w8q5hpelba9k9{noformat}open {"dispatcherId":"jenkins-blueocean-core-js-1487311928759-80shtgg3w8q5hpelba9k9","dispatcherInst":1238701885} 16:15:00.445job {"jenkins_object_type":"org.jenkinsci.plugins.workflow.job.WorkflowRun","jenkins_event_uuid":"6c1358f1-f887-41bb-beb9-3228dda99df8","sse_subs_dispatcher_inst":"1238701885","job_run_status":"SUCCESS","job_name":"scratch/bwalding-alwaysBlue","jenkins_org":"jenkins","job_run_queueId":"5246","jenkins_object_name":"#2","blueocean_job_rest_url":"/blue/rest/organizations/jenkins/pipelines/scratch/pipelines/bwalding-alwaysBlue/","jenkins_object_id":"2","jenkins_event":"job_run_ended","sse_subs_dispatcher":"jenkins-blueocean-core-js-1487311928759-80shtgg3w8q5hpelba9k9","blueocean_job_pipeline_name":"scratch/bwalding-alwaysBlue","jenkins_object_url":"job/scratch/job/bwalding-alwaysBlue/2/","jenkins_channel":"job"} {noformat}Once the frontend receives those events, the frontend then makes a call to retrieve details about the run.https://ci.blueocean.io/blue/rest/organizations/jenkins/pipelines/scratch/pipelines/bwalding-alwaysBlue/runs/2/However the important thing to note is that the bwalding-alwaysBlue job is not visible on the front screen - so the frontend is querying the backend for details on jobs that will not change the state of the front end (afaik)In a large instance that is running a lot of jobs all the time, this could be problematic.
Add Comment
[JIRA] (JENKINS-42137) BlueOcean making unnecessary requests for pipeline run details
Title: Message Title
Ben Walding created an issue
Jenkins / JENKINS-42137
BlueOcean making unnecessary requests for pipeline run details
Issue Type:
Bug
Assignee:
Unassigned
Components:
blueocean-plugin
Created:
2017/Feb/17 6:23 AM
Environment:
b23
Priority:
Minor
Reporter:
Ben Walding
The BlueOcean main pipeline screen has an event websocket thing that is connect to the Jenkins server. On a regular basis this sends event from the backend to the frontend detailing things that are running. (I hope the 80shtgg3w8q5hpelba9k9 ID isn't something important https://ci.blueocean.io/sse-gateway/listen/jenkins-blueocean-core-js-1487311928759-80shtgg3w8q5hpelba9k9
open {"dispatcherId":"jenkins-blueocean-core-js-1487311928759-80shtgg3w8q5hpelba9k9","dispatcherInst":1238701885}
16:15:00.445
job {"jenkins_object_type":"org.jenkinsci.plugins.workflow.job.WorkflowRun","jenkins_event_uuid":"6c1358f1-f887-41bb-beb9-3228dda99df8","sse_subs_dispatcher_inst":"1238701885","job_run_status":"SUCCESS","job_name":"scratch/bwalding-alwaysBlue","jenkins_org":"jenkins","job_run_queueId":"5246","jenkins_object_name":"#2","blueocean_job_rest_url":"/blue/rest/organizations/jenkins/pipelines/scratch/pipelines/bwalding-alwaysBlue/","jenkins_object_id":"2","jenkins_event":"job_run_ended","sse_subs_dispatcher":"jenkins-blueocean-core-js-1487311928759-80shtgg3w8q5hpelba9k9","blueocean_job_pipeline_name":"scratch/bwalding-alwaysBlue","jenkins_object_url":"job/scratch/job/bwalding-alwaysBlue/2/","jenkins_channel":"job"}
[JIRA] (JENKINS-42081) Inconsistent folder title "compaction"
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-42081 Inconsistent folder title "compaction" Change By: Ben Walding To provide context for a given job in a folder structure, we have the path to a job shown as "f[0]/f[1]/f[2]/job"In version b23 of BlueOcean I noticed the behaviour of the compaction changes:On the front screen for 4 or more levels you get:"f[0]/.../f[n]/job" !image-2017-02-16-09-26-30-899.png|thumbnail! On the job display".../.../f[n]/job" !image-2017-02-16-09-27-41-013.png|thumbnail! And then in the build display".../.../f[n]/job"( not note that the underline decoration is shown even when I'm not hovering over it - which is different to other screens) !image-2017-02-16-09-28-42-477.png|thumbnail! I also think that the vertical alignment is a little off, and the underline doesn't look good (in above image), but looks ok once expanded !image-2017-02-16-09-29-10-614.png|thumbnail! Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received
[JIRA] (JENKINS-42081) Inconsistent folder title "compaction"
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-42081 Inconsistent folder title "compaction" Change By: Ben Walding To provide context for a given job in a folder structure, we have the path to a job shown as "f[0]/f[1]/f[2]/job"In version b23 of BlueOcean I noticed the behaviour of the compaction changes:On the front screen for 4 or more levels you get:"f[0]/.../f[n]/job" !image-2017-02-16-09-26-30-899.png|thumbnail! On the job display".../.../f[n]/job" !image-2017-02-16-09-27-41-013.png|thumbnail! And then in the build display".../.../f[n]/job" (not that the underline decoration is shown even when I'm not hovering over it - which is different to other screens)!image-2017-02-16-09-28-42-477.png|thumbnail! I also think that the vertical alignment is a little off, and the underline doesn't look good (in above image), but looks ok once expanded !image-2017-02-16-09-29-10-614.png|thumbnail! Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received
[JIRA] (JENKINS-42081) Inconsistent folder title "compaction"
Title: Message Title Ben Walding created an issue Jenkins / JENKINS-42081 Inconsistent folder title "compaction" Issue Type: Bug Assignee: Unassigned Attachments: image-2017-02-16-09-26-30-899.png, image-2017-02-16-09-27-41-013.png, image-2017-02-16-09-28-42-477.png, image-2017-02-16-09-29-10-614.png Components: blueocean-plugin Created: 2017/Feb/15 11:30 PM Environment: BlueOcean b23 Priority: Trivial Reporter: Ben Walding To provide context for a given job in a folder structure, we have the path to a job shown as "f[0]/f[1]/f[2]/job" In version b23 of BlueOcean I noticed the behaviour of the compaction changes: On the front screen for 4 or more levels you get: "f[0]/.../f[n]/job" On the job display ".../.../f[n]/job"And then in the build display ".../.../f[n]/job"I also think that the vertical alignment is a little off, and the underline doesn't look good (in above image), but looks ok once expanded
[JIRA] (JENKINS-41735) Investigate acceptability of overall performance
Title: Message Title Ben Walding commented on JENKINS-41735 Re: Investigate acceptability of overall performance Well my theory - it was just the volume of items on the page causing the delay - it didn't seem like favourites were exponentially worse than the normal jobs that were displayed on first load. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-41735) Investigate acceptability of overall performance
Title: Message Title Ben Walding commented on JENKINS-41735 Re: Investigate acceptability of overall performance I use vegemite as thermal paste. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-41735) Investigate acceptability of overall performance
Title: Message Title Ben Walding commented on JENKINS-41735 Re: Investigate acceptability of overall performance I'll add my anecdotal data from a short investigation I did today. Using Chrome / Firefox, the web developer consoles say that BO is "ready" after 1.5s. However when I sit watching blueocean load - it's actually around 6s to a usable screen with my jobs loaded. It takes around 800ms to get the main page, and then 900ms to download the jobs. And if I sit watching the consoles, then there is an unexplained 3-4s delay after the jobs are downloaded where BO is "doing nothing", and then everything renders.In the screenshot above, the "idle" period is from 28000ms to 32000ms I also found (in a separate run - don't correlate to above) that scripting is showing up as a major consumer of time Obviously DOM manipulation has to be done - but I don't think I was expecting it to be such a heavy cost. (I have a modern MBP with 4 processors and 16GB of RAM) Enjoy this anecdote! Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-41735) Investigate acceptability of overall performance
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-41735 Investigate acceptability of overall performance Change By: Ben Walding Attachment: screenshot-3.png Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-41735) Investigate acceptability of overall performance
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-41735 Investigate acceptability of overall performance Change By: Ben Walding Attachment: screenshot-2.png Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-41735) Investigate acceptability of overall performance
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-41735 Investigate acceptability of overall performance Change By: Ben Walding Attachment: screenshot-1.png Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-41786) Main search REST query retrieves overlapping data
Title: Message Title Ben Walding created an issue Jenkins / JENKINS-41786 Main search REST query retrieves overlapping data Issue Type: Bug Assignee: Unassigned Components: blueocean-plugin Created: 2017/Feb/07 4:05 AM Priority: Trivial Reporter: Ben Walding The main search query is paged with a page size (limit) of 26. However the start is only incremented by 25 each time. Batch 1: Retrieve start = 0, limit=26 => items 0 - 25 Batch 2: Retrieve start = 25, limit=26 => items 25 - 50 i.e. item 25 has been retrieved twice Add Comment
[JIRA] (JENKINS-39660) Blue Ocean weather icons are difficult to distinguish at smaller sizes
Title: Message Title Ben Walding commented on JENKINS-39660 Re: Blue Ocean weather icons are difficult to distinguish at smaller sizes I'd argue the weather icons are difficult to "distinguish" at any size. i.e. they don't really mean much to me - they are encoded with information that I interpret in a binary fashion - reliably passing - somewhat broken in the past On the front page I have icons as below. I have no idea what they mean apart from the sun probably meaning the build is ok and has been for a while. Also - in classic - the icons are hoverable with build status information - in BlueOcean they have no additional feedback. Icons What is the sorted order? Sunny, clouds, clouds with rain, clouds with lightning? Is that good for usability / discoverability? Hover informationHave I derailed this ticket sufficiently now? Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-39660) Blue Ocean weather icons are difficult to distinguish at smaller sizes
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-39660 Blue Ocean weather icons are difficult to distinguish at smaller sizes Change By: Ben Walding Attachment: screenshot-1.png Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-39660) Blue Ocean weather icons are difficult to distinguish at smaller sizes
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-39660 Blue Ocean weather icons are difficult to distinguish at smaller sizes Change By: Ben Walding Attachment: screenshot-3.png Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-39660) Blue Ocean weather icons are difficult to distinguish at smaller sizes
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-39660 Blue Ocean weather icons are difficult to distinguish at smaller sizes Change By: Ben Walding Attachment: screenshot-2.png Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-39660) Blue Ocean weather icons are difficult to distinguish at smaller sizes
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-39660 Blue Ocean weather icons are difficult to distinguish at smaller sizes Change By: Ben Walding Attachment: screenshot-1.png Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-32938) The Usage Statistics option is randomly displayed in the global configuration page.
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-32938 The Usage Statistics option is randomly displayed in the global configuration page. Change By: Ben Walding The Usage Statistics option is displayed (without a heading) under the * Maven Project Configuation* section in the Jenkins global configuration page. It looks hidden and it is rather This lack of categorisation makes the option less noticeable which may be perceived as unethical / hidden . In OSS: h4. Current Location !usage-stats-oss.png|thumbnail! Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-32938) The Usage Statistics option is randomly displayed in the global configuration page.
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-32938 The Usage Statistics option is randomly displayed in the global configuration page. Change By: Ben Walding The Usage Statistics option is randomly displayed (without a heading) under the Maven in Jenkins global configuration page.It looks hidden and it is rather unethical.In OSS:!usage-stats-oss.png|thumbnail! Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-39425) REGRESSION: NPE when calculating getStartTime chunk time
Title: Message Title
Ben Walding commented on JENKINS-39425
Re: REGRESSION: NPE when calculating getStartTime chunk time
An empty stage triggers it
stage("for the lulz") {
}
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
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-39425) REGRESSION: NPE when calculating getStartTime chunk time
Title: Message Title Ben Walding commented on JENKINS-39425 Re: REGRESSION: NPE when calculating getStartTime chunk time Jenkins 2.28 + BlueOcean b11 - stack trace looks the same - but for the avoidance of doubt Caused by: java.lang.NullPointerException at org.jenkinsci.plugins.workflow.actions.TimingAction.getStartTime(TimingAction.java:45) at org.jenkinsci.plugins.workflow.pipelinegraphanalysis.StatusAndTiming.computeChunkTiming(StatusAndTiming.java:240) at io.jenkins.blueocean.rest.impl.pipeline.PipelineNodeGraphVisitor.handleChunkDone(PipelineNodeGraphVisitor.java:201) at org.jenkinsci.plugins.workflow.graphanalysis.StandardChunkVisitor.chunkStart(StandardChunkVisitor.java:40) at io.jenkins.blueocean.rest.impl.pipeline.PipelineNodeGraphVisitor.chunkStart(PipelineNodeGraphVisitor.java:74) at org.jenkinsci.plugins.workflow.graphanalysis.ForkScanner.visitSimpleChunks(ForkScanner.java:566) at org.jenkinsci.plugins.workflow.graphanalysis.ForkScanner.visitSimpleChunks(ForkScanner.java:551) at io.jenkins.blueocean.rest.impl.pipeline.PipelineNodeGraphVisitor.(PipelineNodeGraphVisitor.java:68) at io.jenkins.blueocean.rest.impl.pipeline.NodeGraphBuilder$NodeGraphBuilderFactory.getInstance(NodeGraphBuilder.java:37) at io.jenkins.blueocean.rest.impl.pipeline.PipelineNodeContainerImpl.(PipelineNodeContainerImpl.java:32) at io.jenkins.blueocean.rest.impl.pipeline.PipelineRunImpl.getNodes(PipelineRunImpl.java:81) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:335) at org.kohsuke.stapler.MetaClass$3.doDispatch(MetaClass.java:197) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:58) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) ... 101 more As a test I created a multibranch pipeline test job that launches a secondary pipeline job (same structure as my failing job) - it did not have the same issue. So there is something subtle about it. Add Comment
[JIRA] (JENKINS-39336) Cannot right click to open results from activity, branches, PR tab
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-39336 Cannot right click to open results from activity, branches, PR tab Change By: Ben Walding Its It is not possible to right - click (or Command-click) and open in a new tab any of the results listed in the activity, branches or PR tabs . Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-39336) Cannot right click to open results from activity, branches, PR tab
Title: Message Title Ben Walding commented on JENKINS-39336 Re: Cannot right click to open results from activity, branches, PR tab Yes - that is a correct characterisation of the limitation. I think the cause is that BlueOcean is not using elements - but is acting on a click at the level. I use "Command" click a lot to open new tabs - and under BlueOcean this is ignored - the tab is transitioned to the new URL rather than opening a new tab. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-38023) Favourite card label does not contain full path
Title: Message Title Ben Walding commented on JENKINS-38023 Re: Favourite card label does not contain full path Speaking to Brody Maclean - the colouring on the folder should be "fill: white, opacity: 0.5" - but at present it is hardcoded to #CCC CurrentPreferred Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-38023) Favourite card label does not contain full path
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-38023 Favourite card label does not contain full path Change By: Ben Walding Attachment: screenshot-2.png Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-38023) Favourite card label does not contain full path
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-38023 Favourite card label does not contain full path Change By: Ben Walding Attachment: screenshot-1.png Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-35656) Inconsistent timezone display
Title: Message Title Ben Walding edited a comment on JENKINS-35656 Re: Inconsistent timezone display Thanks - happy to test once you're happy with it.This plugin still works better (for me) than blueocean for showing me my pipeline builds behaviour.(mainly because I can see builds and stages; whereas in blueocean I can see builds, and then drilling in - the stages for that build - so it is less useful for watching trends)(of course blueocean is keenly aware of my complaining, so I will no doubt get what I want eventually!) Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-35656) Inconsistent timezone display
Title: Message Title Ben Walding commented on JENKINS-35656 Re: Inconsistent timezone display Thanks - happy to test once you're happy with it. This plugin still works better (for me) than blueocean for showing me my pipeline builds behaviour. (mainly because I can builds and stages; whereas in blueocean I can see builds, and then the stages for that build - so it is less useful for watching trends) (of course blueocean is keenly aware of my complaining, so I will no doubt get what I want eventually!) Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-38946) Failed API calls not handled very well
Title: Message Title Ben Walding created an issue Jenkins / JENKINS-38946 Failed API calls not handled very well Issue Type: Improvement Assignee: Unassigned Components: blueocean-plugin Created: 2016/Oct/13 1:58 AM Environment: Jenkins 2.21 + blueocean b08 Priority: Trivial Reporter: Ben Walding When using BlueOcean interface, the interface generally responds quickly. However if there is a problem contacting the Jenkins backend, the UI will either appear to be waiting, or claim to have completed whatever it was doing instantly. Simulating: I have my Jenkins behind a VPN, if I switch off the VPN then the BlueOcean UI does not notice. This could probably be replicated by stopping the Jenkins server (although it might be a slightly different failure). The reason I noticed it was due to favourites - I'd disabled the VPN, and then I clicked to favourite a few items. The favourite star went yellow, but there was no feedback in the UI that the favouriting had failed. Feel free to rewrite this as a specific favourites issue.
[JIRA] (JENKINS-38088) Allow re-run of successful builds
Title: Message Title Ben Walding commented on JENKINS-38088 Re: Allow re-run of successful builds If I only get one, then I don't want this one! Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-36189) Credentials from instance profile?
Title: Message Title Ben Walding commented on JENKINS-36189 Re: Credentials from instance profile? Trevor - I've just raised JENKINS-38220 which is likely the base requirement for the ECR plugin to leverage EC2 instance profiles. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-38220) Support for EC2 instance profile credentials
Title: Message Title
Ben Walding created an issue
Jenkins / JENKINS-38220
Support for EC2 instance profile credentials
Issue Type:
Improvement
Assignee:
Nicolas De Loof
Components:
aws-credentials-plugin
Created:
2016/Sep/14 11:16 PM
Priority:
Minor
Reporter:
Ben Walding
In our AWS environment we avoid using static AWS credentials (i.e. AWS Access Key ID and AWS Secret Access Key) - instead we use ephemeral credentials that are supplied using the Amazon IAM/STS system. i.e. The use of static AWS credentials is not possible in our environment - we need to dynamically acquire credentials on the master / slave to. These credentials are then used to switch roles per our IAM configuration. Once the credentials are acquired, we use those credentials (Access Key ID, Secret Access Key, Session Token) to perform AWS actions as normal. An example As a brief example (from a pipeline script)
env.AWS_ACCESS_KEY_ID = ""
env.AWS_SECRET_ACCESS_KEY = ""
env.AWS_SESSION_TOKEN = ""
roleArn = "arn:aws:iam::<13 character AWS ID>:role/my-custom-role"
externalParam = "--external-id ABCDEFG" // security parameter - optional
json = sh(returnStdout: true,
script: "aws sts assume-role --duration-seconds 3600 --role-arn ${roleARN} --role-session-name rsn ${externalParam}"
def jsonSlurper = new groovy.json.JsonSlurperClassic()
def object = jsonSlurper.parseText(json)
return object.Credentials
Important points
external-id support required
credentials must be acquired on the correct instance
[JIRA] (JENKINS-37666) Preceding step is sometimes erroneously expanded
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-37666 Preceding step is sometimes erroneously expanded Change By: Ben Walding Summary: Proceeding Preceding step is sometimes erroneously expanded Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-38023) Favourite card label does not contain full path
Title: Message Title Ben Walding commented on JENKINS-38023 Re: Favourite card label does not contain full path If we take my example data from ticket: jenkins / build jenkins / deploy-staging jenkins / deploy-production jenkins / build jenkins / deploy-staging jenkins / deploy-production You propose that favourites would look like this, but I could mouse over to find out what they were? I think this is going to be pretty anti-user (well anti-Ben!) - I'd rather just not even use favourites at that point - as they are counter productive. (I do think at a minimum the favourite should match the main list in terms of format) I prefer James option with expansion - however that example is from a single line on a page - where I'd only expand one item. In a list I wouldn't want to be click / hovering over multiple items trying to find the one I was interested in. Solutions with no care to how painful they are to implement In my mind I'd want to see as much information as possible. Then at some point the UI has to start hiding information. jenkins / Applications / www.example.com / build jenkins / Applications / www.example.com / deploy-staging jenkins / Applications / www.example.com / deploy-production jenkins / Applications / login.example.com / build jenkins / Applications / login.example.com / deploy-staging jenkins / Applications / login.example.com / deploy-production If we need to collapse 1 item jenkins / ... / www.example.com / build jenkins / ... / www.example.com / deploy-staging jenkins / ... / www.example.com / deploy-production jenkins / ... / login.example.com / build jenkins / ... / login.example.com / deploy-staging jenkins / ... / login.example.com / deploy-production How do we work out what to collapse? I'll leave that as an exercise for the reader! (I'd collapse "jenkins" before we even started) Add Comment
[JIRA] (JENKINS-38088) Allow re-run of successful builds
Title: Message Title Ben Walding created an issue Jenkins / JENKINS-38088 Allow re-run of successful builds Issue Type: Improvement Assignee: Unassigned Attachments: image-2016-09-09-16-34-06-054.png Components: blueocean-plugin Created: 2016/Sep/09 6:37 AM Environment: 1.0.0.0b4 Priority: Trivial Reporter: Ben Walding The pipeline activity screen shows a row for each build, including a re-run icon. At present you are only allowed to re-run a failed build. It should allow re-run for passed builds too. e.g. I have run a deployment 12,13,14 - 12/14 passed, 13 failed. 14 was deployed successfully, but the smoke-test showed that it was actually no good Thus I want to rollback by rerunning my #12 deployment. Add Comment
[JIRA] (JENKINS-38087) initial search call extremely slow
Title: Message Title
Ben Walding updated an issue
Jenkins / JENKINS-38087
initial search call extremely slow
Change By:
Ben Walding
After a restart of Jenkins, a refresh of the blueocean UI causes a call to the following endpoint: https:// {noformat} < jenkins Jenkins URL >/blue/rest/search/?q=type:pipeline;excludedFromFlattening:jenkins.branch.MultiBranchProject,hudson.matrix.MatrixProject=no-folders=0=26 {noformat} The very first time this runs it is SUPER slow - irrespective of how long the instance has been up and running.I have a 60s timeout on my http frontend - and it hits this and the frontend returns a 504.The second time I reload the UI, it takes ~12s and return 11kB of information (the instance is relatively small).
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
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
[JIRA] (JENKINS-38087) initial search call extremely slow
Title: Message Title Ben Walding created an issue Jenkins / JENKINS-38087 initial search call extremely slow Issue Type: Bug Assignee: Unassigned Components: blueocean-plugin Created: 2016/Sep/09 6:28 AM Priority: Trivial Reporter: Ben Walding After a restart of Jenkins, a refresh of the blueocean UI causes a call to the following endpoint: https:///blue/rest/search/?q=type:pipeline;excludedFromFlattening:jenkins.branch.MultiBranchProject,hudson.matrix.MatrixProject=no-folders=0=26 The very first time this runs it is SUPER slow - irrespective of how long the instance has been up and running. I have a 60s timeout on my http frontend - and it hits this and the frontend returns a 504. The second time I reload the UI, it takes ~12s and return 11kB of information (the instance is relatively small). Add Comment
[JIRA] (JENKINS-38048) Credentials dropdowns empty when configuring external libraries at the global level
Title: Message Title
Ben Walding commented on JENKINS-38048
Re: Credentials dropdowns empty when configuring external libraries at the global level
I was able to add the credentialsId to the xml config and reload to get me past this problem. It also seems that the legacy git provider won't do substitution of $ {library.cloudbees-jenkins-ops-library.version} into the branch specifier. But I'll wait for the rest of the fixes to go through before I investigate that more thoroughly. I worked around that by hardcoding the version into the library. e.g.
> git rev-parse refs/remotes/origin/${library.app.version}^{commit} # timeout=10
> git rev-parse refs/remotes/origin/origin/${library.app.version}^{commit} # timeout=10
> git rev-parse origin/${library.app.version}^{commit} # timeout=10
ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
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-38048) credentials id dropdown not populated
Title: Message Title Ben Walding created an issue Jenkins / JENKINS-38048 credentials id dropdown not populated Issue Type: Bug Assignee: Jesse Glick Attachments: image-2016-09-08-11-04-24-356.png Components: workflow-cps-global-lib-plugin Created: 2016/Sep/08 1:15 AM Environment: Clean docker env - jenkinsci/jenkin - 2.7.1 - recommended plugin loadout + workflow-cps-global-lib (2.3) + workflow-remote-loader (1.2) Priority: Minor Reporter: Ben Walding Adding a "Legacy SCM" git repository. The credentials ID drop down does not populate from existing items, nor do new items get added if I add them while editing the configuration. Console messages These may or may not be relevant (they seem relevant to me) hudson-behavior.js:417 Uncaught TypeError: Cannot read property 'firstChild' of undefinedregisterValidator @ hudson-behavior.js:417(anonymous function) @ behavior.js:111(anonymous function) @ behavior.js:107applySubtree @ behavior.js:93(anonymous function) @ select.js:251 hudson-behavior.js:472 Unable to find nearby scm/id
[JIRA] (JENKINS-38023) Favourite card label does not contain full path
Title: Message Title
Ben Walding edited a comment on JENKINS-38023
Re: Favourite card label does not contain full path
The folder layout that triggered this ticket is shown below [1]The problem is coming up with something sane without requiring twenty configuration options. In my case I need the last 2 items - others might be different. I don't think my example is too far off base though - given how multi-branch pipelines work and how you generally want to organise jobs in Jenkins.I also think the favourite cards should match the non-favourite cards (in a given size) - no matter the rules.(Off topic - the leading "Jenkins" is redundant in my current world-view)[1]{noformat}Applications (folder) www. cloudbees example .com (folder)build (multi-branch pipeline)deploy-staging (pipeline)deploy-production (pipeline) go login . cloudbees example .com (folder)build (multi-branch pipeline)deploy-staging (pipeline)deploy-production (pipeline) ... lots and lots more ...{noformat}
Add Comment
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
--
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-38023) Favourite card label does not contain full path
Title: Message Title Ben Walding commented on JENKINS-38023 Re: Favourite card label does not contain full path The folder layout that triggered this ticket is shown below [1] The problem is coming up with something sane without requiring twenty configuration options. In my case I need the last 2 items - others might be different. I don't think my example is too far off base though - given how multi-branch pipelines work and how you generally want to organise jobs in Jenkins. I also think the favourite cards should match the non-favourite cards (in a given size) - no matter the rules. (Off topic - the leading "Jenkins" is redundant in my current world-view) [1] Applications (folder) www.cloudbees.com (folder) build (multi-branch pipeline) deploy-staging (pipeline) deploy-production (pipeline) go.cloudbees.com (folder) build (multi-branch pipeline) deploy-staging (pipeline) deploy-production (pipeline) ... lots and lots more ... Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-38023) Favorite label does not contain full path
Title: Message Title Ben Walding created an issue Jenkins / JENKINS-38023 Favorite label does not contain full path Issue Type: Bug Assignee: Unassigned Attachments: image-2016-09-07-20-59-12-492.png Components: blueocean-plugin Created: 2016/Sep/07 11:01 AM Environment: blueocean - 1.0.0b2 Priority: Minor Reporter: Ben Walding When a pipeline that exists in a nested path is favorited, it is shown at the top of the screen without the full path. Shown in main list as jenkins / the-folder / the-job, but shown as a favorite jenkins / the-job It is inconsistent, and makes it difficult to find favorited jobs (e.g. I have c/build, d/build, e/build jobs). While I believe this folder structure handling is going to be overhauled in later versions - it seems like this would be a relatively simple fix on the way towards 1.0.
[JIRA] (JENKINS-37236) Unable to negotiate
Title: Message Title Ben Walding commented on JENKINS-37236 Re: Unable to negotiate Some background on why this is now causing issues: http://www.openssh.com/legacy.html https://weakdh.org/ The diffie-hellman-group1-sha1 is insecure and considered "within range" of the LogJam attack. I can confirm this error is a problem on modern OSX machines (using Brew SSH) - as Brew installs OpenSSH v7+ # El Capitan + Brew $ /usr/local/bin/ssh -V OpenSSH_7.3p1, OpenSSL 1.0.2h 3 May 2016 # El Capitan $ /usr/bin/ssh -V OpenSSH_6.9p1, LibreSSL 2.1.8 Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-37745) Tool installer prematurely connecting to download URLs on master
Title: Message Title
Ben Walding updated an issue
Jenkins / JENKINS-37745
Tool installer prematurely connecting to download URLs on master
Change By:
Ben Walding
In the course of investigating a customer issue we discovered It appears that during a tool install, the master is attempting a connection out to a tool installer the remote url - before attempting it on the agent.h4. Stack Trace{noformat}java.io.IOException: Failed to install to at hudson.FilePath.installIfNecessaryFrom(FilePath.java:832) at hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:76) at hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:68) at hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:108) at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:206) {noformat}h4. Forcing a problemOne way to force a failure on the master would be to set a "fail always" hostname verifier on the master (via script console){code}HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() {public boolean verify(String hostname, SSLSession session) { return false;} });{code}h4. DiscussionThe failure was here [1]. But this is happening on the master. We do not really care how the master is configured; we want to do the download from the agent, for builds run in a remote workspace (the recommended configuration). Which it does try to do, starting at line 804, falling back to a slower master-based download only if that fails (for example because the agent has no Internet access). The problem is that we first try to get a URLConnection on the master merely to check the timestamp and other response headers plus status (so we know whether a download is even needed); normally con is then discarded without downloading content. So the fact that a failure occurred in the dummy initial connection (which would ideally be a HEAD not GET) is causing the whole tool installation to fail is a serious problem. For a remote workspace, we should be doing even the metadata checks inside the Unpack callable.It should not really matter whether the master’s settings were broken or not, at least not for purposes of tool downloads. One connection to the tool installer URL would be made, from the agent JVM, which (I hope) would have default Java settings that would work fine.[1] https://github.com/jenkinsci/jenkins/blob/jenkins-1.651.2/core/src/main/java/hudson/FilePath.java#L767
[JIRA] (JENKINS-37745) Tool installer prematurely connecting to download URLs on master
Title: Message Title
Ben Walding updated an issue
Jenkins / JENKINS-37745
Tool installer prematurely connecting to download URLs on master
Change By:
Ben Walding
In the course of investigating a customer issue we discovered that the master is attempting a connection out to a tool installer - before attempting it on the agent.h4. Stack Trace{noformat}java.io.IOException: Failed to install to at hudson.FilePath.installIfNecessaryFrom(FilePath.java:832) at hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:76) at hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:68) at hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:108) at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:206) at org.jenkinsci.plugins.mongodb.MongoDBInstallation.forNode(MongoDBInstallation.java:50) at org.jenkinsci.plugins.mongodb.MongoBu {noformat}h4. Forcing a problemOne way to force a failure on the master would be to set a "fail always" hostname verifier on the master (via script console){code}HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() {public boolean verify(String hostname, SSLSession session) { return false;} });{code}h4. DiscussionThe failure was here [1]. But this is happening on the master. We do not really care how the master is configured; we want to do the download from the agent, for builds run in a remote workspace (the recommended configuration). Which it does try to do, starting at line 804, falling back to a slower master-based download only if that fails (for example because the agent has no Internet access). The problem is that we first try to get a URLConnection on the master merely to check the timestamp and other response headers plus status (so we know whether a download is even needed); normally con is then discarded without downloading content. So the fact that a failure occurred in the dummy initial connection (which would ideally be a HEAD not GET) is causing the whole tool installation to fail is a serious problem. For a remote workspace, we should be doing even the metadata checks inside the Unpack callable.It should not really matter whether the master’s settings were broken or not, at least not for purposes of tool downloads. One connection to the tool installer URL would be made, from the agent JVM, which (I hope) would have default Java settings that would work fine.[1] https://github.com/jenkinsci/jenkins/blob/jenkins-1.651.2/core/src/main/java/hudson/FilePath.java#L767
[JIRA] (JENKINS-37745) Tool installer prematurely connecting to download URLs on master
Title: Message Title
Ben Walding updated an issue
Jenkins / JENKINS-37745
Tool installer prematurely connecting to download URLs on master
Change By:
Ben Walding
In the course of investigating a customer issue we discovered that the master is attempting a connection out to a tool installer - before attempting it on the agent. h4. Stack Trace {noformat}java.io.IOException: Failed to install to at hudson.FilePath.installIfNecessaryFrom(FilePath.java:832) at hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:76) at hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:68) at hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:108) at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:206) at org.jenkinsci.plugins.mongodb.MongoDBInstallation.forNode(MongoDBInstallation.java:50) at org.jenkinsci.plugins.mongodb.MongoBu{noformat}h4. Forcing a problem One way to force a failure on the master would be to set a "fail always" hostname verifier on the master (via script console){code}HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() {public boolean verify(String hostname, SSLSession session) { return false;} });{code} h4. Discussion The failure was here [1]. But this is happening on the master. We do not really care how the master is configured; we want to do the download from the agent, for builds run in a remote workspace (the recommended configuration). Which it does try to do, starting at line 804, falling back to a slower master-based download only if that fails (for example because the agent has no Internet access). The problem is that we first try to get a URLConnection on the master merely to check the timestamp and other response headers plus status (so we know whether a download is even needed); normally con is then discarded without downloading content. So the fact that a failure occurred in the dummy initial connection (which would ideally be a HEAD not GET) is causing the whole tool installation to fail is a serious problem. For a remote workspace, we should be doing even the metadata checks inside the Unpack callable.It should not really matter whether the master’s settings were broken or not, at least not for purposes of tool downloads. One connection to the tool installer URL would be made, from the agent JVM, which (I hope) would have default Java settings that would work fine. {quote} [1] https://github.com/jenkinsci/jenkins/blob/jenkins-1.651.2/core/src/main/java/hudson/FilePath.java#L767
[JIRA] (JENKINS-37745) Tool installer prematurely connecting to download URLs on master
Title: Message Title
Ben Walding updated an issue
Jenkins / JENKINS-37745
Tool installer prematurely connecting to download URLs on master
Change By:
Ben Walding
In the course of investigating a customer issue we discovered that the master is attempting a connection out to a tool installer - before attempting it on the agent. One way to demonstrate this force a failure on the master would be to set a " fail always " hostname verifier on the master (via script console){code}HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() {public boolean verify(String hostname, SSLSession session) { return false;} });{code} {quote}From the stack trace, the The failure is was here [1]. But this is happening on the master. We do not really care how the master is configured; we want to do the download from the agent, for builds run in a remote workspace (the recommended configuration). Which it does try to do, starting at line 804, falling back to a slower master-based download only if that fails (for example because the agent has no Internet access). The problem is that we first try to get a URLConnection on the master merely to check the timestamp and other response headers plus status (so we know whether a download is even needed); normally con is then discarded without downloading content. So the fact that a failure occurred in the dummy initial connection (which would ideally be a HEAD not GET) is causing the whole tool installation to fail is a serious problem. For a remote workspace, we should be doing even the metadata checks inside the Unpack callable.It should not really matter whether the master’s settings were broken or not, at least not for purposes of tool downloads. One connection to the tool installer URL would be made, from the agent JVM, which (I hope) would have default Java settings that would work fine.{quote}[1] https://github.com/jenkinsci/jenkins/blob/jenkins-1.651.2/core/src/main/java/hudson/FilePath.java#L767
Add Comment
[JIRA] (JENKINS-37745) Tool installer prematurely connecting to download URLs on master
Title: Message Title
Ben Walding created an issue
Jenkins / JENKINS-37745
Tool installer prematurely connecting to download URLs on master
Issue Type:
Bug
Assignee:
Jesse Glick
Components:
core
Created:
2016/Aug/29 1:27 AM
Priority:
Minor
Reporter:
Ben Walding
In the course of investigating a customer issue we discovered that the master is attempting a connection out to a tool installer - before attempting it on the agent. One way to demonstrate this failure would be to set a fail always hostname verifier on the master (via script console)
HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() {
public boolean verify(String hostname, SSLSession session) {
return false;
}
}
);
From the stack trace, the failure is here [1]. But this is happening on the master. We do not really care how the master is configured; we want to do the download from the agent, for builds run in a remote workspace (the recommended configuration).
Which it does try to do, starting at line 804, falling back to a slower master-based download only if that fails (for example because the agent has no Internet access).
The problem is that we first try to get a URLConnection on the master merely to check the timestamp and other response headers plus status (so we know whether a download is even needed); normally con is then discarded without downloading content. So the fact that a failure occurred in the dummy initial connection (which
[JIRA] (JENKINS-37666) Proceeding step is sometimes erroneously expanded
Title: Message Title Ben Walding edited a comment on JENKINS-37666 Re: Proceeding step is sometimes erroneously expanded The link in the report is gone now but I can reproduce this - https://ci.blueocean.io/blue/organizations/jenkins/scratch%2Ftst-log-opening/detail/tst-log-opening/1/pipeline/5 (I lied - the original link is fine - it's just uber slow for me) 1. Expand "Shell script" line 1 2. Close "Shell script" line 13. Expand "Shell script" line 2"Shell script" line 1 reopens. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-37666) Proceeding step is sometimes erroneously expanded
Title: Message Title Ben Walding commented on JENKINS-37666 Re: Proceeding step is sometimes erroneously expanded The link in the report is gone now but I can reproduce this - https://ci.blueocean.io/blue/organizations/jenkins/scratch%2Ftst-log-opening/detail/tst-log-opening/1/pipeline/5 1. Expand "Shell script" line 1 2. Close "Shell script" line 1 3. Expand "Shell script" line 2 "Shell script" line 1 reopens. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-37244) Consistent terminology for builds / pipeline runs
Title: Message Title Ben Walding commented on JENKINS-37244 Re: Consistent terminology for builds / pipeline runs Some of my "other thoughts" might also be resolved by parts of JENKINS-35891 Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-37244) Consistent terminology for builds / pipeline runs
Title: Message Title Ben Walding created an issue Jenkins / JENKINS-37244 Consistent terminology for builds / pipeline runs Issue Type: Improvement Assignee: Unassigned Attachments: image-2016-08-08-08-57-50-363.png, image-2016-08-08-08-58-00-957.png Components: blueocean-plugin Created: 2016/Aug/07 11:07 PM Priority: Trivial Reporter: Ben Walding In the build view, the different tabs refer to the "build" by different terms. Current behaviour "build" - "pipeline run" - Expected behaviour Consistent terminology for a given job / pipeline / build. Other thoughts I think a dictionary would be a useful step - similar to the JDL (or contained within it). If it already exists inside the JDL, then I think the next step would be to emit the JDL as an artifact of the build and link to it - i.e. something in here - https://ci.blueocean.io/job/jenkins-design-language/job/master/
[JIRA] (JENKINS-36978) Javascript duplicated in each individual javascript file
Title: Message Title Ben Walding commented on JENKINS-36978 Re: _javascript_ duplicated in each individual _javascript_ file More sensibly... I agree there's no point optimising away those lines if they're going to be bundled up together later on. In the grand scheme of things - worrying about those extra lines of code/comments at the moment doesn't really matter when there's plenty of other stuff to deal with. Ultimately you have many avenues for performance enhancement - bundle, deduplicate / minify, compress, cache Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-36980) intermittent NPE/500 errors after leaving blue ocean open for a while
Title: Message Title Ben Walding commented on JENKINS-36980 Re: intermittent NPE/500 errors after leaving blue ocean open for a while /blue/rest/organizations/jenkins/pipelines//runs/ I don't think it's directly a session / auth issue - this was generated after I had refreshed my main app to ensure session was up to date. java.io.IOException: Failed to write _links at org.kohsuke.stapler.export.Property.safeGetValue(Property.java:151) at org.kohsuke.stapler.export.Property.writeTo(Property.java:126) at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:227) at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:223) at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:223) at org.kohsuke.stapler.export.Property.writeValue(Property.java:279) at org.kohsuke.stapler.export.Property.writeValue(Property.java:222) at org.kohsuke.stapler.export.Property.writeValue(Property.java:168) at org.kohsuke.stapler.export.Property.writeTo(Property.java:139) at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:227) at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:223) at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:223) at org.kohsuke.stapler.export.Model.writeTo(Model.java:198) at org.kohsuke.stapler.ResponseImpl.writeOne(ResponseImpl.java:285) at org.kohsuke.stapler.ResponseImpl.serveExposedBean(ResponseImpl.java:273) at hudson.model.Api.doJson(Api.java:211) at io.jenkins.blueocean.rest.pageable.PagedResponse$Processor$1.generateResponse(PagedResponse.java:55) at org.kohsuke.stapler.HttpResponseRenderer$Default.handleHttpResponse(HttpResponseRenderer.java:124) at org.kohsuke.stapler.HttpResponseRenderer$Default.generateResponse(HttpResponseRenderer.java:69) at org.kohsuke.stapler.Function.renderResponse(Function.java:119) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:102) at org.kohsuke.stapler.IndexDispatcher.dispatch(IndexDispatcher.java:26) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$3.doDispatch(MetaClass.java:196) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:58) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$11.dispatch(MetaClass.java:380) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$11.dispatch(MetaClass.java:380) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$11.dispatch(MetaClass.java:380) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$3.doDispatch(MetaClass.java:196) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:58) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$11.dispatch(MetaClass.java:380) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$11.dispatch(MetaClass.java:380) at
[JIRA] (JENKINS-36978) Javascript duplicated in each individual javascript file
Title: Message Title Ben Walding commented on JENKINS-36978 Re: _javascript_ duplicated in each individual _javascript_ file Conside isomorphic-fetch 1139 lines of boiler plate 480 lines of actual code But you go ahead and mark this WON'T FIX because your operations team will provision an extra 4 servers to deliver all that boilerplate around the world. You're probably right though, the inefficiency of the boilerplate will be swamped by general inefficiencies in Michael's proof-of-concept code that stays in production for 6 years. Hypothetically. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-36978) Javascript duplicated in each individual javascript file
Title: Message Title Ben Walding commented on JENKINS-36978 Re: _javascript_ duplicated in each individual _javascript_ file You're lucky this is a public JIRA or I'd tell you what I really thought of your lack of care and respect for the contributing community you have. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-36980) NPE/500 errors after leaving blue ocean open for a while in RebuildPlugin
Title: Message Title
Ben Walding updated an issue
Jenkins / JENKINS-36980
NPE/500 errors after leaving blue ocean open for a while in RebuildPlugin
Change By:
Ben Walding
Uncovered by [~bwalding]: Request: 500 error accessing /blue/organizations/jenkins/build/activityPage: /blue/rest/organizations/jenkins/pipelines//build/runs/ {noformat}Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.GeneratedMethodAccessor108.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.kohsuke.stapler.export.MethodProperty.getValue(MethodProperty.java:66) at org.kohsuke.stapler.export.Property.safeGetValue(Property.java:145) ... 111 moreCaused by: java.lang.NullPointerException at com.sonyericsson.rebuild.RebuildAction.isRebuildDisbaled(RebuildAction.java:370) at com.sonyericsson.rebuild.RebuildAction.isRebuildAvailable(RebuildAction.java:360) at com.sonyericsson.rebuild.RebuildAction.getUrlName(RebuildAction.java:186) at io.jenkins.blueocean.service.embedded.rest.ActionProxiesImpl.getUrlName(ActionProxiesImpl.java:33) at io.jenkins.blueocean.service.embedded.rest.ActionProxiesImpl.getLink(ActionProxiesImpl.java:43) at io.jenkins.blueocean.rest.hal.Links.getOrCreateSelfRef(Links.java:123) at io.jenkins.blueocean.rest.hal.Links.init>(Links.java:52) at io.jenkins.blueocean.rest.model.Resource.getLinks(Resource.java:38) ... 116 more{noformat}*The original trace came from an internal instance - bwalding can supply more information and request info on the instance if required*This points to this line: https://github.com/jenkinsci/rebuild-plugin/blob/master/src/main/java/com/sonyericsson/rebuild/RebuildAction.java#L152 possiblyCurrently he is using google auth for identity, and it seems to happen after 30 minutes. Reloading the page causes things to work again just fine. On theory is that session is not re-established cleanly and the null is the api is trying to access things in an unauthenticated state. Investigation required.
Add Comment
[JIRA] (JENKINS-36980) NPE/500 errors after leaving blue ocean open for a while in RebuildPlugin
Title: Message Title
Ben Walding updated an issue
Jenkins / JENKINS-36980
NPE/500 errors after leaving blue ocean open for a while in RebuildPlugin
Change By:
Ben Walding
Uncovered by [~bwalding]: https {noformat}Caused by : //gist java . github lang . reflect.InvocationTargetException at sun.reflect.GeneratedMethodAccessor108.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.kohsuke.stapler.export.MethodProperty.getValue(MethodProperty.java:66) at org.kohsuke.stapler.export.Property.safeGetValue(Property.java:145) ... 111 moreCaused by: java.lang.NullPointerException at com / .sonyericsson.rebuild.RebuildAction.isRebuildDisbaled(RebuildAction.java:370) at com.sonyericsson.rebuild.RebuildAction.isRebuildAvailable(RebuildAction.java:360) at com.sonyericsson.rebuild.RebuildAction.getUrlName(RebuildAction.java:186) at io.jenkins.blueocean.service.embedded.rest.ActionProxiesImpl.getUrlName(ActionProxiesImpl.java:33) at io.jenkins.blueocean.service.embedded.rest.ActionProxiesImpl.getLink(ActionProxiesImpl.java:43) at io.jenkins.blueocean.rest.hal.Links.getOrCreateSelfRef(Links.java:123) at io.jenkins.blueocean.rest.hal.Links.init>(Links.java:52) at io.jenkins.blueocean.rest.model.Resource.getLinks(Resource.java:38) ... 116 more{noformat}*The original trace came from an internal instance - bwalding /9d12d52371eb708c527ce93b786e36c0 can supply more information and request info on the instance if required* This points to this line: https://github.com/jenkinsci/rebuild-plugin/blob/master/src/main/java/com/sonyericsson/rebuild/RebuildAction.java#L152 possiblyCurrently he is using google auth for identity, and it seems to happen after 30 minutes. Reloading the page causes things to work again just fine. On theory is that session is not restablished re-established cleanly and the null is the api is trying to access things in an unauthenticated state. Investigation required.
Add Comment
[JIRA] (JENKINS-36978) Javascript duplicated in each individual javascript file
Title: Message Title Ben Walding created an issue Jenkins / JENKINS-36978 _javascript_ duplicated in each individual _javascript_ file Issue Type: Bug Assignee: Unassigned Components: blueocean-plugin Created: 2016/Jul/27 3:52 AM Environment: dogfood server - ci.blueocean.io Priority: Minor Reporter: Ben Walding Overview There are 1113 lines of _javascript_ code being duplicated into multiple files being returned under blueocean. Expected _javascript_ not duplicated unnecessarily Actual e.g. consider two (of many) resources returned by ci.blueocean.io https://ci.blueocean.io/adjuncts/1a7b49ee/org/jenkins/ui/jsmodules/keymirror/keymirror-0.1.1.js https://ci.blueocean.io/adjuncts/1a7b49ee/org/jenkins/ui/jsmodules/history/history-2.0.2.js The first 1113 lines are duplicated into each resource
[JIRA] (JENKINS-36943) favorites that are failing have a reload button that doesn't do anything
Title: Message Title Ben Walding created an issue Jenkins / JENKINS-36943 favorites that are failing have a reload button that doesn't do anything Issue Type: Improvement Assignee: Unassigned Attachments: image-2016-07-26-17-38-18-080.png Components: blueocean-plugin Created: 2016/Jul/26 7:41 AM Priority: Minor Reporter: Ben Walding Overview In the favorites personalisation area, there are a list of favorited jobs. Jobs that experienced a failure in their last completed build are shown as red with a non functional reload icon. Expected The reload icon is removed or does something (rebuilds failed job/build) Actual The reload icon is static Add Comment
[JIRA] (JENKINS-36942) favorites are not clickable
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-36942 favorites are not clickable Change By: Ben Walding Summary: favorites are not clickable Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-36942) favorites are clickable
Title: Message Title Ben Walding created an issue Jenkins / JENKINS-36942 favorites are clickable Issue Type: Improvement Assignee: Unassigned Attachments: image-2016-07-26-17-33-08-150.png Components: blueocean-plugin Created: 2016/Jul/26 7:35 AM Priority: Minor Reporter: Ben Walding Overview The favourites area should accelerate usage of the interface "Expected" The favourite link in the personalized area should be clickable Actual The favourite link is not clickable (and is missing folder names - JENKINS-36488) Add Comment
[JIRA] (JENKINS-36895) favorite star layout issues if running at page zoom < 100%
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-36895 favorite star layout issues if running at page zoom < 100% Change By: Ben Walding Attachment: image-2016-07-23-12-10-54-717.png Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-36895) favorite star layout issues if running at page zoom < 100%
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-36895 favorite star layout issues if running at page zoom < 100% Change By: Ben Walding Attachment: image-2016-07-23-12-11-18-019.png h3. Overview* set page zoom to 90%* look at favorite starsh3. ExpectedFavorite stars are fully formedFavorite stars are alignedh3. Actual Favorite stars are slightly clippedFavorite stars are not horizontally aligned (note - one of my jobs is not triggered by commits - but by scheduled polling - I suspect that is the cause of some of the layout issue - no commit identifier) !image-2016-07-23-12-05-35-016.png|thumbnail! !image-2016-07-23-12- 10 11 - 54 18 - 717 019 .png|thumbnail! Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are
[JIRA] (JENKINS-36895) favorite star layout issues if running at page zoom < 100%
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-36895 favorite star layout issues if running at page zoom < 100% Change By: Ben Walding Summary: favorite star clipped layout issues if running at page zoom < 100% Attachment: image-2016-07-23-12-10-54-717.png h3. Overview* set page zoom to 90%* look at favorite starsh3. Expected Favourite Favorite stars are fully formed Favorite stars are aligned h3. Actual Favourite Favorite stars are slightly clipped Favorite stars are not horizontally aligned!image-2016-07-23-12-05-35-016.png|thumbnail! !image-2016-07-23-12-10-54-717.png|thumbnail! Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-36895) favorite star clipped if running at page zoom < 100%
Title: Message Title Ben Walding created an issue Jenkins / JENKINS-36895 favorite star clipped if running at page zoom < 100% Issue Type: Improvement Assignee: Unassigned Attachments: image-2016-07-23-12-05-35-016.png Components: blueocean-plugin Created: 2016/Jul/23 2:07 AM Environment: Chrome on OSX Blueocean plugin pack 1.0-alpha-4 Priority: Trivial Reporter: Ben Walding Overview set page zoom to 90% look at favorite stars Expected Favourite stars are fully formed Actual Favourite stars are slightly clipped Add Comment
[JIRA] (JENKINS-36790) Code flagged as "ElasticBox confidential" committed to Github
Title: Message Title Ben Walding created an issue Jenkins / JENKINS-36790 Code flagged as "ElasticBox confidential" committed to Github Issue Type: Task Assignee: Unassigned Components: elasticbox-plugin Created: 2016/Jul/19 8:50 AM Priority: Minor Reporter: Ben Walding Code in the Elasticbox plugin (located in JenkinsCI Github) has "confidential" headers in many files. https://github.com/jenkinsci/elasticbox-plugin/search?utf8=%E2%9C%93=confidential I can't see any written permission location in the repo. /* * ElasticBox Confidential * Copyright (c) 2015 All Right Reserved, ElasticBox Inc. * * NOTICE: All information contained herein is, and remains the property * of ElasticBox. The intellectual and technical concepts contained herein are * proprietary and may be covered by U.S. and Foreign Patents, patents in process, * and are protected by trade secret or copyright law. Dissemination of this * information or reproduction of this material is strictly forbidden unless prior * written permission is obtained from ElasticBox. */
[JIRA] (JENKINS-36782) SCM identifiers too small
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-36782 SCM identifiers too small Change By: Ben Walding The font used for SCM identifiers on the main pipeline screen is too small (inherited from a code CSS selector) h3 . Procedure e.g. # Browse to an activity view: https://ci.blueocean.io/blue/organizations/jenkins/Acceptance%20Tests/activity/#Acceptance Tests-82 h3. ExpectedFonts are consistently sized in any given viewh3. Actual The font used for SCM identifiers on the main pipeline screen is too small (inherited from a code CSS selector).e.g. !image-2016-07-19-11-29-46-775.png|thumbnail! Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-36781) Display of SCM identifiers should be consistent
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-36781 Display of SCM identifiers should be consistent Change By: Ben Walding h3. Procedure# Browse the blueocean interface# Main view has commits like 1234567# Build view has commits like #12345678h3. Expected : Commit identifiers are consistent throughout the user interface. h3. Actual : Different screens in blueocean use differently formatted identifiers for Git commits (or more generally SCM identifiers I would assume). Notably 1234567 vs #12345678 for the same commit. Git tends to use 7 digit for the short format. !screenshot-1.png|thumbnail! !screenshot-2.png|thumbnail! Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-36783) Artifact download links rely on mime type to determine download vs. view
Title: Message Title Ben Walding created an issue Jenkins / JENKINS-36783 Artifact download links rely on mime type to determine download vs. view Issue Type: Improvement Assignee: Unassigned Attachments: image (1).png Components: blueocean-plugin Created: 2016/Jul/19 1:37 AM Priority: Minor Reporter: Ben Walding Procedure Browse to a build that has produced artifacts (test.html, test.blob). Click on test.html (it will be viewed) Click on test.blob (it will be downloaded) Expected Clicking on the artifact "download" link should always download the artifact. There should probably be an alternate "view" link. This would be consistent with the log screen which has download and view links. A download (and filename) should be forced using Content-Disposition. Actual Some mime-types are downloaded, some are viewed *.html are opened for view, *.unknown are downloaded.
[JIRA] (JENKINS-36782) SCM identifiers too small
Title: Message Title Ben Walding created an issue Jenkins / JENKINS-36782 SCM identifiers too small Issue Type: Improvement Assignee: Unassigned Attachments: image-2016-07-19-11-29-46-775.png Components: blueocean-plugin Created: 2016/Jul/19 1:30 AM Priority: Minor Reporter: Ben Walding The font used for SCM identifiers on the main pipeline screen is too small (inherited from a code CSS selector). e.g. https://ci.blueocean.io/blue/organizations/jenkins/Acceptance%20Tests/activity/#Acceptance Tests-82 Add Comment
[JIRA] (JENKINS-36781) Display of SCM identifiers should be consistent
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-36781 Display of SCM identifiers should be consistent Change By: Ben Walding Expected: Commit identifiers are consistent throughout the user interface.Actual: Different screens in blueocean use different differently formatted identifiers for Git commits (or more generally SCM identifiers I would assume). Notably 1234567 vs # 1234567 12345678 for the same commit. (I personally prefer the #1234567 format - for consistency with other systems - otherwise it's just a Git tends to use 7 digit hex - but probably best to consider more than just Git) for the short format .! image screenshot - 2016 1.png|thumbnail! !screenshot - 07-19-11-22-19-102 2 .png|thumbnail! Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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
[JIRA] (JENKINS-36781) Display of SCM identifiers should be consistent
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-36781 Display of SCM identifiers should be consistent Change By: Ben Walding Attachment: screenshot-2.png Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-36781) Display of SCM identifiers should be consistent
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-36781 Display of SCM identifiers should be consistent Change By: Ben Walding Attachment: screenshot-1.png Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-36781) Display of SCM identifiers should be consistent
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-36781 Display of SCM identifiers should be consistent Change By: Ben Walding Attachment: image-2016-07-19-11-22-19-102.png Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-36781) Display of SCM identifiers should be consistent
Title: Message Title Ben Walding created an issue Jenkins / JENKINS-36781 Display of SCM identifiers should be consistent Issue Type: Improvement Assignee: Unassigned Components: blueocean-plugin Created: 2016/Jul/19 1:26 AM Priority: Minor Reporter: Ben Walding Expected: Commit identifiers are consistent throughout the user interface. Actual: Different screens in blueocean use different identifiers for Git commits (or more generally SCM identifiers I would assume). Notably 1234567 vs #1234567 for the same commit. (I personally prefer the #1234567 format - for consistency with other systems - otherwise it's just a 7 digit hex - but probably best to consider more than just Git). Unable to render embedded object: File (image-2016-07-19-11-22-19-102.png) not found. Add Comment
[JIRA] (JENKINS-36023) Estimated stage duration miscalculated for in-progress builds
Title: Message Title Ben Walding created an issue Jenkins / JENKINS-36023 Estimated stage duration miscalculated for in-progress builds Issue Type: Bug Assignee: Sam Van Oort Attachments: image-2016-06-17-08-42-05-437.png Components: pipeline-stage-view-plugin Created: 2016/Jun/16 10:46 PM Priority: Minor Reporter: Ben Walding The estimate duration of the stage includes builds which are still running. E.g. Build #1 where stage "Wait for CloudFront" took 15 minutes Build #2 where stage "Wait for CloudFront" is in progress, currently around 1 minutes. The view is estimating that the stage will take 8 minutes ((15 + 1) / 2). Obviously this is incorrect, the best estimate is actually 15 minutes, the average stage duration for all completed builds. We can have the discussion on estimate of builds with outliers at some other point (e.g. in BlueOcean) - but excluding builds that are in-progress from the calculation makes sense to me. Add Comment
[JIRA] [pipeline-stage-view-plugin] (JENKINS-35656) Inconsistent timezone display
Title: Message Title Ben Walding updated an issue Jenkins / JENKINS-35656 Inconsistent timezone display Change By: Ben Walding The pipeline stage view displays the build time using local time (i.e. my personal time zone).!stageview.png |width=298,height=142 !While the left hand build list shows in UTC.!build.png |width=476,height=72 !(yes, the screenshots are from the same build! I will investigate the different status indicators shortly!!)Jenkins - 1.651.2Pipeline Stage View Plugin - 1.4Stage View: Local time (+1000)Build View (left hand): UTC (+)Operating System: UTC (+)Jenkins Timezone: UTCI'm not opposed to local time, but my preference is for consistency (and a hover showing exact UTC time) 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] [pipeline-stage-view-plugin] (JENKINS-35656) Inconsistent timezone display
Title: Message Title Ben Walding created an issue Jenkins / JENKINS-35656 Inconsistent timezone display Issue Type: Bug Assignee: Sam Van Oort Attachments: build.png, stageview.png Components: pipeline-stage-view-plugin Created: 2016/Jun/12 9:28 PM Priority: Minor Reporter: Ben Walding The pipeline stage view displays the build time using local time (i.e. my personal time zone). While the left hand build list shows in UTC. (yes, the screenshots are from the same build! I will investigate the different status indicators shortly!!) Jenkins - 1.651.2 Pipeline Stage View Plugin - 1.4 Stage View: Local time (+1000) Build View (left hand): UTC (+) Operating System: UTC (+) Jenkins Timezone: UTC I'm not opposed to local time, but my preference is for consistency (and a hover showing exact UTC time)
[JIRA] [_unsorted] (JENKINS-34460) domain-discover - ping to discover-jenkins. is done over http irrespective of the scheme used for the connection to Jenkins.
Title: Message Title Ben Walding created an issue Jenkins / JENKINS-34460 domain-discover - ping to discover-jenkins. is done over http irrespective of the scheme used for the connection to Jenkins. Issue Type: Improvement Assignee: Oleg Nenashev Components: _unsorted Created: 2016/Apr/26 11:28 PM Priority: Minor Reporter: Ben Walding (no component for domain-discover exists) Imagine I connected to a secure HTTPS Jenkins with a "secret" in the URL and the domain-discover pinger worked - it would report the secret over http to the discover-jenkins endpoint (as the full URL is transferred in the referer) 1) Should only the hostname (and or IP address) reported to discover-jenkins (I.e. is it worth reporting a payload - privacy concerns of course) 2) Putting this on by default might cause some entertaining side effects in public hosting infrastructure - e.g. openshift / cloudbees depending on their vhosting layout - I would register a customer discover-jenkins and all customers would report to them (if the hosting provider didn't disable the module) 3) should the ping use the same scheme as the incoming request?; and should it check the certs (to avoid MITM)? IMO - with the introduction of LetsEncrypt there is no reason not to have valid https all the time - even for relative low value instances.
