[JIRA] (JENKINS-60623) Failed to count the # of live instances on Kubernetes after upgrade to 1.22.3 for slaves with multiple labes
Title: Message Title
Steve Berube commented on JENKINS-60623
Re: Failed to count the # of live instances on Kubernetes after upgrade to 1.22.3 for slaves with multiple labes
Can confirm the same issue 2020-01-08 16:54:02.768+ [id=59] WARNING o.c.j.p.k.KubernetesCloud#provision: Failed to count the # of live instances on Kubernetes2020-01-08 16:54:02.768+ [id=59] WARNING o.c.j.p.k.KubernetesCloud#provision: Failed to count the # of live instances on Kubernetesio.fabric8.kubernetes.client.KubernetesClientException: Failure executing: GET at: https://hcm-cicd.hpeswlab.net:8443/api/v1/namespaces/cicd/pods?labelSelector=jenkins%3Dslave%2Cjenkins%2Flabel%3Ddeployment%20maven%20nodejs%20python%20aujas%20seleniumgrid. Message: found 'maven', expected: ',' or 'end of string'. Received status: Status(apiVersion=v1, code=400, details=null, kind=Status, message=found 'maven', expected: ',' or 'end of string', metadata=ListMeta(_continue=null, remainingItemCount=null, resourceVersion=null, selfLink=null, additionalProperties={}), reason=BadRequest, status=Failure, additionalProperties={}).
Add Comment
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203855.1577961309000.4923.1578502740219%40Atlassian.JIRA.
[JIRA] (JENKINS-33273) Optimize Jenkinsfile loading and branch detection
Title: Message Title Steve Berube commented on JENKINS-33273 Re: Optimize Jenkinsfile loading and branch detection One more update. If you configure your PR strategy to be Build Pull Request Revision, this works around the issue and it can read the jenkinsfile via the API. 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-33273) Optimize Jenkinsfile loading and branch detection
Title: Message Title Steve Berube commented on JENKINS-33273 Re: Optimize Jenkinsfile loading and branch detection seems a limitation: https://support.cloudbees.com/hc/en-us/articles/115002991272-Why-is-my-multibranch-project-cloning-the-whole-repository-on-the-master- 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-33273) Optimize Jenkinsfile loading and branch detection
Title: Message Title
Steve Berube edited a comment on JENKINS-33273
Re: Optimize Jenkinsfile loading and branch detection
The issue appears to be fixed on main branches, however pull requests still appear to be checking out the entire repo vs just getting the Jenkinsfile. e.g. Pull Request.{code:java}Pull request #14924 opened05:15:28 Connecting to https://github.houston.softwaregrp.net/api/v3 using steve-berube/** (GITHUB Service Account (Using Steve Berube))Checking out git https://github.houston.softwaregrp.net/CSA/csa.gitinto /var/jenkins_home/workspace/A_CSA-PIPELINE_csa_PR-14924-Z4QJL7VGNYZFORO2QDHYKCLF6JHNT2KX6T7GPPU2XP5ECHCOF7EQ@script to read JenkinsfileCloning the remote Git repository{code} E.g. Non-pull request. {code:java}originally caused by:Push event to branch v04.93.00022:58:31 Connecting to https://github.houston.softwaregrp.net/api/v3 using steve-berube/** (GITHUB Service Account (Using Steve Berube))Obtained Jenkinsfile from 2bfe852c7aad46b7dc90ffb6e53c2b177f07ae00Running in Durability level: MAX_SURVIVABILITY{code} Another example{code:java}originally caused by:Push event to branch v04.93.00022:58:31 Connecting to https://github.houston.softwaregrp.net/api/v3 using steve-berube/** (GITHUB Service Account (Using Steve Berube))Obtained Jenkinsfile from 2bfe852c7aad46b7dc90ffb6e53c2b177f07ae00 Running in Durability level: MAX_SURVIVABILITY{code} Is this a limitation or a defect?
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
[JIRA] (JENKINS-33273) Optimize Jenkinsfile loading and branch detection
Title: Message Title Steve Berube updated an issue Jenkins / JENKINS-33273 Optimize Jenkinsfile loading and branch detection Change By: Steve Berube Comment: This appears to still be an issue when using the job type 'Github Organization' using a multi-branch job type it downloads the jenkinsfile directly. Using a Github Organization job type exhibits the original behavior described in this defect. 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-33273) Optimize Jenkinsfile loading and branch detection
Title: Message Title
Steve Berube edited a comment on JENKINS-33273
Re: Optimize Jenkinsfile loading and branch detection
The issue appears to be fixed on main branches, however pull requests still appear to be checking out the entire repo vs just getting the Jenkinsfile. e.g. Pull Request. {code:java} Pull request #14924 opened05:15:28 Connecting to [ https://github.houston.softwaregrp.net/api/v3 ] using steve-berube/** (GITHUB Service Account (Using Steve Berube))Checking out git [ https://github.houston.softwaregrp.net/CSA/csa.git ] into /var/jenkins_home/workspace/A_CSA-PIPELINE_csa_PR-14924-Z4QJL7VGNYZFORO2QDHYKCLF6JHNT2KX6T7GPPU2XP5ECHCOF7EQ@script to read Jenkinsfile Cloning the remote Git repository {code} E.g. Non-pull request. ``` {code:java} originally caused by: Push event to branch v04.93.00022:58:31 Connecting to [ https://github.houston.softwaregrp.net/api/v3 ] using steve-berube/** (GITHUB Service Account (Using Steve Berube))Obtained Jenkinsfile from 2bfe852c7aad46b7dc90ffb6e53c2b177f07ae00 Running in Durability level: MAX_SURVIVABILITY ``` {code} Another example {code:java}originally caused by: Push event to branch v04.93.00022: 13 58 : 44 31 Connecting to [ https://github.houston.softwaregrp.net/api/v3 ] using steve-berube/** (GITHUB Service Account (Using Steve Berube))Obtained Jenkinsfile from d0cc5b9a1364a55bfc8db096300f169d0275e3cc 2bfe852c7aad46b7dc90ffb6e53c2b177f07ae00 Running in Durability level: MAX_SURVIVABILITY {code} Is this a limitation or a defect?
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
--
You received this message
[JIRA] (JENKINS-33273) Optimize Jenkinsfile loading and branch detection
Title: Message Title Steve Berube edited a comment on JENKINS-33273 Re: Optimize Jenkinsfile loading and branch detection This The issue appears to be fixed on main branches, however pull requests still appear to be an issue when using 'Github Organization' type job. Using checking out the same settings we can see this: entire repo vs just getting the Jenkinsfile. e.g. Pull Request.Pull request # 15009 updated 03 14924 opened05 : 57 15 : 55 28 Connecting to [https://github.houston.softwaregrp.net/api/v3] using steve-berube/** (GITHUB Service Account (Using Steve Berube)) Checking out git[https://github.houston.softwaregrp.net/CSA/csa.git] into /var/jenkins_home/workspace/A_CSA-PIPELINE_csa_PR- 15009 14924 - YTM6TGDT23IHVZJWIJFKF3ADHRCGDWVO3WVR2WXIF65GTANXEENA Z4QJL7VGNYZFORO2QDHYKCLF6JHNT2KX6T7GPPU2XP5ECHCOF7EQ @script to read Jenkinsfile > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from Cloning the remote Git repository > git config remote E . origin g . url Non-pull request. originally caused by: Push event to branch v04.93.00022:58:31 Connecting to [https://github.houston.softwaregrp.net/ CSA api / csa.git v3 ] # timeout=10 Cleaning workspace > git rev using steve - parse --verify HEAD # timeout=10 Resetting working tree > git reset --hard # timeout=10 berube/** (GITHUB Service Account (Using Steve Berube))Obtained Jenkinsfile from 2bfe852c7aad46b7dc90ffb6e53c2b177f07ae00 Running in Durability level: MAX_SURVIVABILITY Where as when using just the multibranch type job Another example It downloads just the Jenkinsfile directly over the API Push event to branch v04 . Both are using 93.00022:13:44 Connecting to [https:// github. houston.softwaregrp.net/api/v3] using steve-berube/** (GITHUB Service Account (Using Steve Berube))Obtained Jenkinsfile from d0cc5b9a1364a55bfc8db096300f169d0275e3cc Running in Durability level: MAX_SURVIVABILITY One more update, it appears to only happen on PRIVATE repos. Is this a limitation or a defect? Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
[JIRA] (JENKINS-33273) Optimize Jenkinsfile loading and branch detection
Title: Message Title Steve Berube edited a comment on JENKINS-33273 Re: Optimize Jenkinsfile loading and branch detection The issue appears to be fixed on main branches, however pull requests still appear to be checking out the entire repo vs just getting the Jenkinsfile. e.g. Pull Request.Pull request #14924 opened05:15:28 Connecting to [https://github.houston.softwaregrp.net/api/v3] using steve-berube/** (GITHUB Service Account (Using Steve Berube))Checking out git [https://github.houston.softwaregrp.net/CSA/csa.git] into /var/jenkins_home/workspace/A_CSA-PIPELINE_csa_PR-14924-Z4QJL7VGNYZFORO2QDHYKCLF6JHNT2KX6T7GPPU2XP5ECHCOF7EQ@script to read JenkinsfileCloning the remote Git repository E.g. Non-pull request. ``` originally caused by: Push event to branch v04.93.00022:58:31 Connecting to [https://github.houston.softwaregrp.net/api/v3] using steve-berube/** (GITHUB Service Account (Using Steve Berube))Obtained Jenkinsfile from 2bfe852c7aad46b7dc90ffb6e53c2b177f07ae00Running in Durability level: MAX_SURVIVABILITY ``` Another examplePush event to branch v04.93.00022:13:44 Connecting to [https://github.houston.softwaregrp.net/api/v3] using steve-berube/** (GITHUB Service Account (Using Steve Berube))Obtained Jenkinsfile from d0cc5b9a1364a55bfc8db096300f169d0275e3ccRunning in Durability level: MAX_SURVIVABILITY Is this a limitation or a defect? 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
[JIRA] (JENKINS-33273) Optimize Jenkinsfile loading and branch detection
Title: Message Title Steve Berube edited a comment on JENKINS-33273 Re: Optimize Jenkinsfile loading and branch detection This appears to still be an issue when using 'Github Organization' type job. Using the same settings we can see this: Pull request #15009 updated 03:57:55 Connecting to [https://github.houston.softwaregrp.net/api/v3] using steve-berube/** (GITHUB Service Account (Using Steve Berube)) Checking out git[https://github.houston.softwaregrp.net/CSA/csa.git]into /var/jenkins_home/workspace/A_CSA-PIPELINE_csa_PR-15009-YTM6TGDT23IHVZJWIJFKF3ADHRCGDWVO3WVR2WXIF65GTANXEENA@script to read Jenkinsfile > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url[https://github.houston.softwaregrp.net/CSA/csa.git] # timeout=10 Cleaning workspace > git rev-parse --verify HEAD # timeout=10 Resetting working tree > git reset --hard # timeout=10 Where as when using just the multibranch type jobIt downloads just the Jenkinsfile directly over the API. Both are using github . One more update, it appears to only happen on PRIVATE repos. 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-33273) Optimize Jenkinsfile loading and branch detection
Title: Message Title Steve Berube reopened an issue This appears to still be an issue when using 'Github Organization' type job. Using the same settings we can see this: Pull request #15009 updated 03:57:55 Connecting to https://github.houston.softwaregrp.net/api/v3 using steve-berube/** (GITHUB Service Account (Using Steve Berube)) Checking out git https://github.houston.softwaregrp.net/CSA/csa.git into /var/jenkins_home/workspace/A_CSA-PIPELINE_csa_PR-15009-YTM6TGDT23IHVZJWIJFKF3ADHRCGDWVO3WVR2WXIF65GTANXEENA@script to read Jenkinsfile > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url https://github.houston.softwaregrp.net/CSA/csa.git timeout=10 Cleaning workspace > git rev-parse --verify HEAD # timeout=10 Resetting working tree > git reset --hard # timeout=10 Where as when using just the multibranch type job It downloads just the Jenkinsfile directly over the API. Both are using github Jenkins / JENKINS-33273 Optimize Jenkinsfile loading and branch detection Change By: Steve Berube Resolution: Fixed Status: Resolved Reopened Add Comment
[JIRA] (JENKINS-33273) Optimize Jenkinsfile loading and branch detection
Title: Message Title Steve Berube commented on JENKINS-33273 Re: Optimize Jenkinsfile loading and branch detection This appears to still be an issue when using the job type 'Github Organization' using a multi-branch job type it downloads the jenkinsfile directly. Using a Github Organization job type exhibits the original behavior described in this defect. 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-37718) Block Pipeline job while upstream or downstream projects are building
Title: Message Title Steve Berube commented on JENKINS-37718 Re: Block Pipeline job while upstream or downstream projects are building This would be very useful for us as well. 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-50250) 1.13 to 1.3.1 kubernets plugin no longer able to override jnlp container
Title: Message Title Steve Berube commented on JENKINS-50250 Re: 1.13 to 1.3.1 kubernets plugin no longer able to override jnlp container Yes that approach has worked fine for us. There was one build we tried of the plugin which it failed to work but was fixed almost immediately by the development team. Our biggest challenge is memory management in the pods and JVM allocation. The doc on this isn't great unfortunately. But not part of this issue. 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-33273) Optimize Jenkinsfile loading and branch detection
Title: Message Title Steve Berube commented on JENKINS-33273 Re: Optimize Jenkinsfile loading and branch detection Would love to see this fixed too. One of our repos is gigantic and the prep-phase takes forever just to get a single jenkinsfile. 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-50250) 1.13 to 1.3.1 kubernets plugin no longer able to override jnlp container
Title: Message Title Steve Berube commented on JENKINS-50250 Re: 1.13 to 1.3.1 kubernets plugin no longer able to override jnlp container The field where I have specified jnlp 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-50250) 1.13 to 1.3.1 kubernets plugin no longer able to override jnlp container
Title: Message Title Steve Berube updated an issue Jenkins / JENKINS-50250 1.13 to 1.3.1 kubernets plugin no longer able to override jnlp container Change By: Steve Berube Attachment: image-2018-03-28-08-13-13-607.png 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-50250) 1.13 to 1.3.1 kubernets plugin no longer able to override jnlp container
Title: Message Title Steve Berube commented on JENKINS-50250 Re: 1.13 to 1.3.1 kubernets plugin no longer able to override jnlp container I closed my own ticket because of confirmed it’s working in 1.3.1. I’ll double check it works in1.4.0 and report back 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-50250) 1.13 to 1.3.1 kubernets plugin no longer able to override jnlp container
Title: Message Title Steve Berube resolved as Fixed To resolve this, I changed the name to something else, let containers deploy, changed it back and it worked properly. Closing issue. Jenkins / JENKINS-50250 1.13 to 1.3.1 kubernets plugin no longer able to override jnlp container Change By: Steve Berube Status: Open Resolved Resolution: Fixed 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
[JIRA] (JENKINS-50250) 1.13 to 1.3.1 kubernets plugin no longer able to override jnlp container
Title: Message Title Steve Berube created an issue Jenkins / JENKINS-50250 1.13 to 1.3.1 kubernets plugin no longer able to override jnlp container Issue Type: Bug Assignee: Carlos Sanchez Components: kubernetes-plugin Created: 2018-03-19 13:23 Environment: Jenkins 2.111, CentOS 7.4 Priority: Major Reporter: Steve Berube I am unclear if this was a functionality change or if we were exploiting a bug. We have built our own JNLP container, and from 0.99 to 1.13 we were able to set the container name in the pod template to jnlp and it would pull and use our defined container. After 1.1.3 we can no longer do that. If we specify jnlp in the container it ignores our container and uses the default jnlp one. If this is a functionality change, what is the new way to override the default jnlp container? Add Comment
