[JIRA] (JENKINS-60243) Blue Ocean Input Step Json Error
Title: Message Title Christian Ciach commented on JENKINS-60243 Re: Blue Ocean Input Step Json Error This is probably a duplicate of https://issues.jenkins-ci.org/browse/JENKINS-41662 Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203225.1574343655000.7565.1586264760277%40Atlassian.JIRA.
[JIRA] (JENKINS-60243) Blue Ocean Input Step Json Error
Title: Message Title Christian Ciach edited a comment on JENKINS-60243 Re: Blue Ocean Input Step Json Error This is probably a duplicate of https://issues.jenkins-ci.org/browse/ JENKINS-41662 Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.203225.1574343655000.7567.1586264760309%40Atlassian.JIRA.
[JIRA] (JENKINS-41662) Proceed button fails (investigate)
Title: Message Title Christian Ciach commented on JENKINS-41662 Re: Proceed button fails (investigate) We are seeing the same issue with BlueOcean 1.22.0. Do you guys use a reverse proxy? We are using Caddy 2 as a reverse proxy and i suspect that it could be the culprit. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.178489.1486047513000.6869.1586172360701%40Atlassian.JIRA.
[JIRA] (JENKINS-59781) sshCommand fails to flush full log on failure
Title: Message Title
Christian Ciach edited a comment on JENKINS-59781
Re: sshCommand fails to flush full log on failure
This issue does not only apply to failures, but all logging of this plugin (even its own status logging, like "{{Executing command on name[server]: mycommand sudo: false"}}).Looking at the code, it seems to me that the likely issue is a missing flush()-call to the CustomLogHandler (or maybe the rootLogger) at the end of this method: [https://github.com/jenkinsci/ssh-steps-plugin/blob/c35e7db86e975b257343179fd4f08dd0af8cbb42/src/main/groovy/org/jenkinsci/plugins/sshsteps/SSHService.groovy#L55]That being said.. Is it really a good Idea to register a new CustomLogHandler every time something gets logged? The rootLogger is most likely static, so adding new handlers for each and every message will eventually lead to a ton of CustomLogHandlers that are probably never garbage collected. Edit: I also wonder why this plugin logs its own messages through the "org.hidetake"-Logger instead of using its own logger.
Add Comment
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202509.157108516.3601.1585663440333%40Atlassian.JIRA.
[JIRA] (JENKINS-59781) sshCommand fails to flush full log on failure
Title: Message Title
Christian Ciach edited a comment on JENKINS-59781
Re: sshCommand fails to flush full log on failure
This issue does not only apply to failures, but all logging of this plugin (even its own status logging, like "{{Executing command on name[server]: mycommand sudo: false"}}).Looking at the code, it seems to me that the likely issue is a missing flush()-call to the CustomLogHandler (or maybe the rootLogger) at the end of this method: [https://github.com/jenkinsci/ssh-steps-plugin/blob/c35e7db86e975b257343179fd4f08dd0af8cbb42/src/main/groovy/org/jenkinsci/plugins/sshsteps/SSHService.groovy#L55]That being said.. Is it really a good Idea to register a new CustomLogHandler every time something gets logged? The rootLogger is most likely static, so adding new handlers for each and every message will eventually lead to a ton of CustomLogHandlers that are probably never garbage collected. Edit: I also wonder why this plugin logs its own messages through the "org.hidetake"-Logger instead of using its own logger.
Add Comment
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202509.157108516.3605.1585663440452%40Atlassian.JIRA.
[JIRA] (JENKINS-59781) sshCommand fails to flush full log on failure
Title: Message Title
Christian Ciach edited a comment on JENKINS-59781
Re: sshCommand fails to flush full log on failure
This issue does not only apply to failures, but all logging of this plugin (even its own status logging, like "{{Executing command on name[server]: mycommand sudo: false"}}).Looking at the code, it seems to me that the likely issue is a missing flush()-call to the CustomLogHandler (or maybe the rootLogger) at the end of this method: [https://github.com/jenkinsci/ssh-steps-plugin/blob/c35e7db86e975b257343179fd4f08dd0af8cbb42/src/main/groovy/org/jenkinsci/plugins/sshsteps/SSHService.groovy#L55]That being said.. Is it really a good Idea to register a new CustomLogHandler every time something gets logged? The rootLogger is most likely static, so adding new handlers for each and every message will eventually lead to a ton of CustomLogHandlers that are probably never garbage collected.
Add Comment
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202509.157108516.3582.1585659067589%40Atlassian.JIRA.
[JIRA] (JENKINS-57765) No output returned from sshCommand
Title: Message Title
Christian Ciach edited a comment on JENKINS-57765
Re: No output returned from sshCommand
I, too, see the issue with the highly asynchronous log output of this plugin. Even status logging (for example: "{{Executing command on name[server]: mycommand sudo: false"}}) is highly out of sync to the rest of the log (and sometimes doesn't get logged at all), making the log very confusing to read. This is an issue with this plugin, because these messages are written by the plugin itself. This doesn't have anything to do with the underlying groovy-ssh library.Looking at the code, it seems to me that the likely issue is a missing flush()-call to the CustomLogHandler (or maybe the rootLogger) at the end of this method: [https://github.com/jenkinsci/ssh-steps-plugin/blob/c35e7db86e975b257343179fd4f08dd0af8cbb42/src/main/groovy/org/jenkinsci/plugins/sshsteps/SSHService.groovy#L55]That being said.. Is it really a good Idea to register a new CustomLogHandler every time something gets logged? The rootLogger is most likely static, so adding new handlers for each and every message will eventually lead to a ton of CustomLogHandlers that are probably never garbage collected.
Add Comment
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.199712.155923150.3586.1585659067763%40Atlassian.JIRA.
[JIRA] (JENKINS-59781) sshCommand fails to flush full log on failure
Title: Message Title Christian Ciach commented on JENKINS-59781 Re: sshCommand fails to flush full log on failure This issue does not only apply to failures, but all logging of this plugin (even its own status logging, like "Executing command on name[server]: mycommand sudo: false"). Looking at the code, it seems to me that the likely issue is a missing flush()-call to the CustomLogHandler (or maybe the rootLogger) at the end of this method: https://github.com/jenkinsci/ssh-steps-plugin/blob/c35e7db86e975b257343179fd4f08dd0af8cbb42/src/main/groovy/org/jenkinsci/plugins/sshsteps/SSHService.groovy#L55 That being said.. Is it really a good Idea to register a new CustomLogHandler every time something gets logged? Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.202509.157108516.3578.1585658700170%40Atlassian.JIRA.
[JIRA] (JENKINS-57765) No output returned from sshCommand
Title: Message Title
Christian Ciach edited a comment on JENKINS-57765
Re: No output returned from sshCommand
I, too, see the issue with the highly asynchronous log output of this plugin. Even status logging (for example: "{{Executing command on name[server]: mycommand sudo: false"}}) is highly out of sync to the rest of the log (and sometimes doesn't get logged at all), making the log very confusing to read. This is an issue with this plugin, because these messages are written by the plugin itself. This doesn't have anything to do with the underlying groovy-ssh library.Looking at the code, it looks seems to me like that the likely issue is a missing flush()-call to the CustomLogHandler (or maybe the rootLogger) at the end of this method: [https://github.com/jenkinsci/ssh-steps-plugin/blob/c35e7db86e975b257343179fd4f08dd0af8cbb42/src/main/groovy/org/jenkinsci/plugins/sshsteps/SSHService.groovy#L55]That being said.. Is it really a good Idea to register a new CustomLogHandler every time something gets logged?
Add Comment
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.199712.155923150.3568.1585657620196%40Atlassian.JIRA.
[JIRA] (JENKINS-57765) No output returned from sshCommand
Title: Message Title
Christian Ciach edited a comment on JENKINS-57765
Re: No output returned from sshCommand
I, too, see the issue with the highly asynchronous log output of this plugin. Even status logging (for example: "{{Executing command on name[server]: mycommand sudo: false"}}) is highly out of sync to the rest of the log (and sometimes doesn't get logged at all), making the log very confusing to read. This is an issue with this plugin, because these messages are written by the plugin itself. This doesn't have anything to do with the underlying groovy-ssh library. Looking at the code, it looks to me like the likely issue is a missing flush()-call to the CustomLogHandler (or maybe the rootLogger) at the end of this method: [https://github.com/jenkinsci/ssh-steps-plugin/blob/c35e7db86e975b257343179fd4f08dd0af8cbb42/src/main/groovy/org/jenkinsci/plugins/sshsteps/SSHService.groovy#L55]That being said.. Is it really a good Idea to register a new CustomLogHandler every time something gets logged?
Add Comment
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.199712.155923150.3563.1585657560282%40Atlassian.JIRA.
[JIRA] (JENKINS-57765) No output returned from sshCommand
Title: Message Title
Christian Ciach edited a comment on JENKINS-57765
Re: No output returned from sshCommand
I, too, see the issue with the highly asynchronous log output of this plugin. Even status logging ( like for example: "{{Executing command on name[server]: mycommand sudo: false"}}) is highly out of sync to the rest of the log (and sometimes doesn't get logged at all), making the log very confusing to read.Looking at the code, it looks to me like the likely issue is a missing flush()-call to the CustomLogHandler (or maybe the rootLogger) at the end of this method: [https://github.com/jenkinsci/ssh-steps-plugin/blob/c35e7db86e975b257343179fd4f08dd0af8cbb42/src/main/groovy/org/jenkinsci/plugins/sshsteps/SSHService.groovy#L55]That being said.. Is it really a good Idea to register a new CustomLogHandler every time something gets logged?
Add Comment
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.199712.155923150.3558.1585657440259%40Atlassian.JIRA.
[JIRA] (JENKINS-57765) No output returned from sshCommand
Title: Message Title Christian Ciach commented on JENKINS-57765 Re: No output returned from sshCommand I, too, see the issue with the highly asynchronous log output of this plugin. Even status logging (like "Executing command on name[server]: mycommand sudo: false") is highly out of sync to the rest of the log (and sometimes doesn't get logged at all), making the log very confusing to read. Looking at the code, it looks to me like the likely issue is a missing flush()-call to the CustomLogHandler (or maybe the rootLogger) at the end of this method: https://github.com/jenkinsci/ssh-steps-plugin/blob/c35e7db86e975b257343179fd4f08dd0af8cbb42/src/main/groovy/org/jenkinsci/plugins/sshsteps/SSHService.groovy#L55 That being said.. Is it really a good Idea to register a new CustomLogHandler every time something gets logged? Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.199712.155923150.3553.1585657260242%40Atlassian.JIRA.
[JIRA] (JENKINS-58778) [ sshPut ] unable to copy only contents inside folder. put always copying full folder
Title: Message Title
Christian Ciach edited a comment on JENKINS-58778
Re: [ sshPut ] unable to copy only contents inside folder. put always copying full folder
Maybe we could do something like that as a workaround:{code:java}findFiles(glob: 'Build/rpms/*.rpm').each { rpmFile -> sshPut remote: remote, from: rpmFile.path, into: '/data/mirror/rpm-repo'}{code}This feels a bit dirty this probably has negative performance implications, because this establishes a new SSH-connection for each file.It would be great if this plugin could provide a "flatten" parameter for the sshPut-step, like the publish-over-ssh plugin: [https://wiki.jenkins.io/display/JENKINS/Publish+Over#PublishOver-Flattenfiles]Or, alternatively, allow a wildcard for the "from"-parameter of the sshPut-step, so we could use "Build/rpms/*" instead of "Build/rpms" as the source.The underlying library allow allows many kinds of "from" parameters (like Iterables), not just Strings. Maybe this jenkins plugin could be modified so that not only Strings are permitted as the "from" parameter? At least maybe allow Iterables, too?
Add Comment
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.201087.156473320.12069.1585061640173%40Atlassian.JIRA.
[JIRA] (JENKINS-58778) [ sshPut ] unable to copy only contents inside folder. put always copying full folder
Title: Message Title
Christian Ciach edited a comment on JENKINS-58778
Re: [ sshPut ] unable to copy only contents inside folder. put always copying full folder
Maybe we could do something like that as a workaround:{code:java}findFiles(glob: 'Build/rpms/*.rpm').each { rpmFile -> sshPut remote: remote, from: rpmFile.path, into: '/data/mirror/rpm-repo'}{code}This feels a bit dirty this probably has negative performance implications, because this establishes a new SSH-connection for each file.It would be great if this plugin could provide a "flatten" parameter for the sshPut-step, like the publish-over-ssh plugin: [https://wiki.jenkins.io/display/JENKINS/Publish+Over#PublishOver-Flattenfiles]Or, alternatively, allow a wildcard for the "from"-parameter of the sshPut-step, so we could use "Build/rpms/*" instead of "Build/rpms" as the source. The underlying library allow many kinds of "from" parameters (like Iterables), not just Strings. Maybe this jenkins plugin could be modified so that not only Strings are permitted as the "from" parameter? At least maybe allow Iterables, too?
Add Comment
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.201087.156473320.12056.1585059840211%40Atlassian.JIRA.
[JIRA] (JENKINS-58778) [ sshPut ] unable to copy only contents inside folder. put always copying full folder
Title: Message Title
Christian Ciach commented on JENKINS-58778
Re: [ sshPut ] unable to copy only contents inside folder. put always copying full folder
Maybe we could do something like that as a workaround:
findFiles(glob: 'Build/rpms/*.rpm').each { rpmFile ->
sshPut remote: remote, from: rpmFile.path, into: '/data/mirror/rpm-repo'
}
This feels a bit dirty this probably has negative performance implications, because this establishes a new SSH-connection for each file. It would be great if this plugin could provide a "flatten" parameter for the sshPut-step, like the publish-over-ssh plugin: https://wiki.jenkins.io/display/JENKINS/Publish+Over#PublishOver-Flattenfiles Or, alternatively, allow a wildcard for the "from"-parameter of the sshPut-step, so we could use "Build/rpms/*" instead of "Build/rpms" as the source. The underlying library allow many kinds of "from" parameters (like Iterables), not just Strings. Maybe this jenkins plugin could be modified so that not only Strings are permitted as the "from" parameter? At least maybe allow Iterables, too?
Add Comment
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsub
[JIRA] (JENKINS-58778) [ sshPut ] unable to copy only contents inside folder. put always copying full folder
Title: Message Title
Christian Ciach edited a comment on JENKINS-58778
Re: [ sshPut ] unable to copy only contents inside folder. put always copying full folder
Maybe we could do something like that as a workaround: {code:java}findFiles(glob: 'Build/rpms/*.rpm').each { rpmFile -> sshPut remote: remote, from: rpmFile.path, into: '/data/mirror/rpm-repo'}{code}This feels a bit dirty this probably has negative performance implications, because this establishes a new SSH-connection for each file.It would be great if this plugin could provide a "flatten" parameter for the sshPut-step, like the publish-over-ssh plugin: [https://wiki.jenkins.io/display/JENKINS/Publish+Over#PublishOver-Flattenfiles]Or, alternatively, allow a wildcard for the "from"-parameter of the sshPut-step, so we could use "Build/rpms/*" instead of "Build/rpms" as the source. The underlying library allow many kinds of "from" parameters (like Iterables), not just Strings. Maybe this jenkins plugin could be modified so that not only Strings are permitted as the "from" parameter? At least maybe allow Iterables, too?
Add Comment
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.201087.156473320.12036.1585059300344%40Atlassian.JIRA.
[JIRA] (JENKINS-58778) [ sshPut ] unable to copy only contents inside folder. put always copying full folder
Title: Message Title Christian Ciach commented on JENKINS-58778 Re: [ sshPut ] unable to copy only contents inside folder. put always copying full folder I second this request and I couldn't find a solution for this, too. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.201087.156473320.12029.1585058640202%40Atlassian.JIRA.
[JIRA] (JENKINS-59548) Automatically enable "Deploy Key" for Gitlab project
Title: Message Title
Christian Ciach updated an issue
Jenkins / JENKINS-59548
Automatically enable "Deploy Key" for Gitlab project
Change By:
Christian Ciach
To enable Jenkins to checkout our Git projects from Gitlab, the "Deploy Key" of Jenkins currently must be enabled for each project in Gitlab individually.This is a tedious task that can be automated using the Gitlab API.A practical example: # In Gitlab, go to "Admin Area" -> "Deploy Keys" and add a new key that we will call "jenkins-gitlab". # To enable Jenkins to checkout the source code of the project named "MyProject", we must enable the deploy key for this project in Gitlab. For this, I currently have to go to the Settings of the Gitlab-Project gitlab project "MyProject" manually ("Settings" -> "Repository" -> "Deploy Keys") to enable the Deploy Key called "jenkins-gitlab").Using the gitlab-branch-source-plugin, this is the only thing I currently still have to do manually for each new gitlab project.Fortunately, this could be automated using the Gitlab API. Please have a look at the section "Enable a deploy key": [https://docs.gitlab.com/ce/api/deploy_keys.html#enable-a-deploy-key|https://docs.gitlab.com/ee/api/deploy_keys.html#enable-a-deploy-key]If would be really great if I could configure the "Deploy Key" to use at organization-folder level in Gitlab (or maybe even as a system setting) that "gitlab-branch-source-plugin" uses to automatically call the Gitlab API to enable the deploy config for the gitlab projects. I think this should be offered as a trait that shows a combobox of available Deploy Keys. To fill the combox of available Deploy Keys, you can use this API: [ https://docs.gitlab.com/ce/api/deploy_keys.html#list-all-deploy-keys ]
Add Comment
[JIRA] (JENKINS-59548) Automatically enable "Deploy Key" for Gitlab project
Title: Message Title
Christian Ciach updated an issue
Jenkins / JENKINS-59548
Automatically enable "Deploy Key" for Gitlab project
Change By:
Christian Ciach
To enable Jenkins to checkout our Git projects from Gitlab, the "Deploy Key" of Jenkins currently must be enabled for each project in Gitlab individually.This is a tedious task that can be automated using the Gitlab API.A practical example: # In Gitlab, go to "Admin Area" -> "Deploy Keys" and add a new key that we will call "jenkins-gitlab". # To enable Jenkins to checkout the source code of the project named "MyProject", we must enable the deploy key for this project in Gitlab. For this, I currently have to go to the Settings of the Gitlab-Project manually ("Settings" -> "Repository" -> "Deploy Keys") to enable the Deploy Key called "jenkins-gitlab").Using the gitlab-branch-source-plugin, this is the only thing I currently still have to do manually for each new gitlab project.Fortunately, this could be automated using the Gitlab API. Please have a look at the section "Enable a deploy key": [https://docs.gitlab.com/ ce/api/deploy_keys.html#enable-a-deploy-key|https://docs.gitlab.com/ ee/api/deploy_keys.html#enable-a-deploy-key]If would be really great if I could configure a the "Deploy Token title Key " to use at organization-folder level in Gitlab (or maybe even as a system setting) that "gitlab-branch-source-plugin" uses to automatically call the Gitlab API to enable the deploy config for the gitlab projects. I think this should be offered as a trait that shows a combobox of available Deploy Keys. To fill the combox of available Deploy Keys, you can use this API: https://docs.gitlab.com/ce/api/deploy_keys.html#list-all-deploy-keys
Add Comment
[JIRA] (JENKINS-59548) Automatically enable "Deploy Key" for Gitlab project
Title: Message Title
Christian Ciach updated an issue
Jenkins / JENKINS-59548
Automatically enable "Deploy Key" for Gitlab project
Change By:
Christian Ciach
To enable Jenkins to checkout our Git projects from Gitlab, the "Deploy Key" of Jenkins currently must be enabled for each project in Gitlab individually.This is a tedious task that can be automated using the Gitlab API.A practical example: # In Gitlab, go to "Admin Area" -> "Deploy Keys" and add a new key that we will call "jenkins-gitlab". # If To enable Jenkins should be able to checkout the source code of the project named "MyProject", we must enable the deploy key for this project. For this, I currently have to go to the Settings of the Gitlab-Project manually ("Settings" -> "Repository" -> "Deploy Keys") to enable the Deploy Key called "jenkins-gitlab").Using the gitlab-branch-source-plugin, this is the only thing I currently still have to do manually for each new gitlab project.Fortunately, this could be automated using the Gitlab API. Please have a look at the section "Enable a deploy key": [https://docs.gitlab.com/ee/api/deploy_keys.html#enable-a-deploy-key]If would be really great if I could configure a "Deploy Token title" at organization-folder level in Gitlab (or maybe even as a system setting) that "gitlab-branch-source-plugin" uses to automatically call the Gitlab API to enable the deploy config for the gitlab projects.
Add Comment
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
[JIRA] (JENKINS-59548) Automatically enable "Deploy Key" for Gitlab project
Title: Message Title
Christian Ciach updated an issue
Jenkins / JENKINS-59548
Automatically enable "Deploy Key" for Gitlab project
Change By:
Christian Ciach
To enable Jenkins to checkout our Git projects from Gitlab, the "Deploy Key" of Jenkins currently must be enabled for each project in Gitlab individually.This is a tedious task that can be automated using the Gitlab API.A practical example: # In Gitlab, go to "Admin Area" -> "Deploy Keys" and add a new key that we will call "jenkins-gitlab". # To enable Jenkins to checkout the source code of the project named "MyProject", we must enable the deploy key for this project in Gitlab . For this, I currently have to go to the Settings of the Gitlab-Project manually ("Settings" -> "Repository" -> "Deploy Keys") to enable the Deploy Key called "jenkins-gitlab").Using the gitlab-branch-source-plugin, this is the only thing I currently still have to do manually for each new gitlab project.Fortunately, this could be automated using the Gitlab API. Please have a look at the section "Enable a deploy key": [https://docs.gitlab.com/ee/api/deploy_keys.html#enable-a-deploy-key]If would be really great if I could configure a "Deploy Token title" at organization-folder level in Gitlab (or maybe even as a system setting) that "gitlab-branch-source-plugin" uses to automatically call the Gitlab API to enable the deploy config for the gitlab projects.
Add Comment
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
[JIRA] (JENKINS-59548) Automatically enable "Deploy Key" for Gitlab project
Title: Message Title
Christian Ciach created an issue
Jenkins / JENKINS-59548
Automatically enable "Deploy Key" for Gitlab project
Issue Type:
New Feature
Assignee:
Christian Ciach
Components:
gitlab-branch-source-plugin
Created:
2019-09-26 14:14
Priority:
Minor
Reporter:
Christian Ciach
To enable Jenkins to checkout our Git projects from Gitlab, the "Deploy Key" of Jenkins currently must be enabled for each project in Gitlab individually.This is a tedious task that can be automated using the Gitlab API. A practical example:
In Gitlab, go to "Admin Area" -> "Deploy Keys" and add a new key that we will call "jenkins-gitlab".
If Jenkins should be able to checkout the source code of the project named "MyProject", we must enable the deploy key for this project. For this, I currently have to go to the Settings of the Gitlab-Project manually ("Settings" -> "Repository" -> "Deploy Keys") to enable the Deploy Key called "jenkins-gitlab").
Using the gitlab-branch-source-plugin, this is the only thing I currently still have to do manually for each new gitlab project. Fortunately, this could be automated using the Gitlab API. Please have a look at the section "Enable a deploy key": https://docs.gitlab.com/ee/api/deploy_keys.html#enable-a-deploy-key If would be really great if I could configure a "Deploy Token title" at organization-folder level in Gitlab (or maybe even as a system setting) that "gitlab-branch-source-plugin" uses to automatically call the Gitlab API to enable the deploy config for the gitlab projects.
[JIRA] (JENKINS-59444) Please respect build strategy "Skip initial build on first branch indexing"
Title: Message Title Christian Ciach closed an issue as Not A Defect Jenkins / JENKINS-59444 Please respect build strategy "Skip initial build on first branch indexing" Change By: Christian Ciach Status: Open Closed Resolution: Not A Defect 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.202029.1568889065000.1060.1568890980388%40Atlassian.JIRA.
[JIRA] (JENKINS-59444) Please respect build strategy "Skip initial build on first branch indexing"
Title: Message Title Christian Ciach commented on JENKINS-59444 Re: Please respect build strategy "Skip initial build on first branch indexing" It was actually a bad configuration. For future readers, please see the corrected configuration attached. 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.202029.1568889065000.1058.1568890861047%40Atlassian.JIRA.
[JIRA] (JENKINS-59444) Please respect build strategy "Skip initial build on first branch indexing"
Title: Message Title Christian Ciach updated an issue Jenkins / JENKINS-59444 Please respect build strategy "Skip initial build on first branch indexing" Change By: Christian Ciach Attachment: corrected_skip_initial_build.png 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.202029.1568889065000.1056.1568890800256%40Atlassian.JIRA.
[JIRA] (JENKINS-59444) Please respect build strategy "Skip initial build on first branch indexing"
Title: Message Title Christian Ciach commented on JENKINS-59444 Re: Please respect build strategy "Skip initial build on first branch indexing" Actually, maybe I am doing it wrong. See here: JENKINS-58254 I will try out the workaround there and will update this issue accordingly. 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.202029.1568889065000.1041.1568889180118%40Atlassian.JIRA.
[JIRA] (JENKINS-59444) Please respect build strategy "Skip initial build on first branch indexing"
Title: Message Title Christian Ciach created an issue Jenkins / JENKINS-59444 Please respect build strategy "Skip initial build on first branch indexing" Issue Type: Bug Assignee: Parichay Barpanda Attachments: skip_initial_build.png Components: gitlab-branch-source-plugin Created: 2019-09-19 10:31 Environment: Gitlab-Branch-Source 1.3.0 Basic Branch Build Strategies Plugin 1.3.2 Jenkins 2.195 OpenJDK 11.0.4 CentOS 7 Priority: Minor Reporter: Christian Ciach Hi and thank you again for this great plugin! We are using the "Basic Branch Build Strategies Plugin" to configure which branches to automatically build on changes. I think this is a core plugin by now, but I am not completely sure about that. As you can see from the screenshot attached, there is a build strategy called "Skip initial build on first branch indexing" that is very important for us. We have a whole lot of Branches and Tags and it really hurts the jenkins when all of these clog the build queue when first importing Gitlab projects using your fine plugin. Unfortunately it seems like "Gitlab-Branch-Source" plugin doesn't honor the setting "Skip initial build on first branch indexing". Every time the plugin finds a new gitlab project, the build queue immediately fills up with hundreds of branches and tags.
[JIRA] (JENKINS-59184) Do not serve project icons directly from gitlab server
Title: Message Title Christian Ciach commented on JENKINS-59184 Re: Do not serve project icons directly from gitlab server If anyhow possible I think the Avatar should be copied to and served by jenkins. This assumes that you can access the actual image file through the gitlab api to copy the file over. If this is not possible, then I don't have a strong opinion about how to solve this. I just think jenkins should never ever show a broken image (to be exact, the browser shows no image at all when the user isn't currently logged into gitlab). Making this configurable as a trait would be just a workaround. I still wish to see the actual avatars of the gitlab projects, but I think there should be a way to archive that even if the user is currently logged out from gitlab. If course, this is only a minor issue and not a deal breaker at all. You shouldn't make it a priority to fix this for the next release (I think it is a much bigger deal that all branches and tags are automatically built when first importing a project into jenkins, even when using "skip initial build" of the "Build strategy plugin". I will try to validate this bug tomorrow before issuing a bug report.) 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.201622.156742570.6807.1567625460120%40Atlassian.JIRA.
[JIRA] (JENKINS-59184) Do not serve project icons directly from gitlab server
Title: Message Title Christian Ciach created an issue Jenkins / JENKINS-59184 Do not serve project icons directly from gitlab server Issue Type: Task Assignee: Parichay Barpanda Components: gitlab-branch-source-plugin Created: 2019-09-02 12:01 Environment: Plugin version 1.2.0 Priority: Minor Reporter: Christian Ciach I think it's great that this plugin uses the same project icons as configured in Gitlab, but I think you shouldn't directly link to the image hosted by Gitlab. Not every Jenkins user has access to our Gitlab server. And even if they have, they may not be logged in into Gitlab. Because of this, Jenkins just shows a broken image instead the project icon. If possible, I think these project icons should be copied into Jenkins and be served by Jenkens to the users. Add Comment
[JIRA] (JENKINS-56231) Suppress automatic SCM triggering is deprecated
Title: Message Title Christian Ciach commented on JENKINS-56231 Re: Suppress automatic SCM triggering is deprecated The deprecation is part of JENKINS-47859 The JavaDoc of the class `NoTriggerBranchProperty` says: @deprecated Replaced by a named branch build strategy in the basic-branch-build-strategies plugin Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56294) dockerfile: ARG in FROM breaks docker inspect
Title: Message Title
Christian Ciach updated an issue
Jenkins / JENKINS-56294
dockerfile: ARG in FROM breaks docker inspect
Change By:
Christian Ciach
Please note that there is already an issue with a very similar name regarding the docker-workflow plugin here: https://issues.jenkins-ci.org/browse/JENKINS-46105The issue actually has been fixed already at the docker-workflow plugin, but the pipeline-model-definition-plugin fails to take advantage of that.The issue in a nutshell:I have this Dockerfile (excerpt): {code:java}ARG VERSION=latestFROM repo-vp.development.ems:5000/emsys-adoptopenjdk11:${VERSION}{code} This is part of my declarative Jenkinsfile:{code:java}stage('Build') { agent { dockerfile { filename 'Dockerfile' additionalBuildArgs "--build-arg VERSION=jdk-11.0.2.9" reuseNode true} } steps {(...) }}{code} This results in a failed build with the following error log:{code:java}java.io.IOException: Cannot retrieve .Id from 'docker inspect repo-vp.development.ems:5000/emsys-adoptopenjdk11:${VERSION}' at org.jenkinsci.plugins.docker.workflow.client.DockerClient.inspectRequiredField(DockerClient.java:220) at org.jenkinsci.plugins.docker.workflow.FromFingerprintStep$Execution.run(FromFingerprintStep.java:133) at org.jenkinsci.plugins.docker.workflow.FromFingerprintStep$Execution.run(FromFingerprintStep.java:85) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:47) at hudson.security.ACL.impersonate(ACL.java:290) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:44) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)Finished: FAILURE{code}This has already been fixed by the docker-workflow plugin (see JENKINS-46105), but "pipeline-model-definition" has yet to take advantage of that.Please see this line in your plugin: [https://github.com/jenkinsci/pipeline-model-definition-plugin/blob/7502d14aa4db891302abf48a2c7de7c9ced97f95/pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/DockerPipelineFromDockerfileScript.groovy#L83]As you can see, you don't pass the new parameter "buildArgs" to the instance of `dockerFingerprintFrom`. See the setter here: [https://github.com/jenkinsci/docker-workflow-plugin/blob/dbeb7cf23961fdb5cbc495e8067bd42c56dcdfc5/src/main/java/org/jenkinsci/plugins/docker/workflow/FromFingerprintStep.java#L81]If you just pass the build-args to this step, the issue should be resolved.
[JIRA] (JENKINS-56294) dockerfile: ARG in FROM breaks docker inspect
Title: Message Title
Christian Ciach created an issue
Jenkins / JENKINS-56294
dockerfile: ARG in FROM breaks docker inspect
Issue Type:
Bug
Assignee:
Andrew Bayer
Components:
pipeline-model-definition-plugin
Created:
2019-02-26 15:51
Environment:
docker-workflow 1.17, pipeline-model-definition 1.3.4.1, Jenkins 2.165
Priority:
Minor
Reporter:
Christian Ciach
Please note that there is already an issue with a very similar name regarding the docker-workflow plugin here: https://issues.jenkins-ci.org/browse/JENKINS-46105 The issue actually has been fixed already at the docker-workflow plugin, but the pipeline-model-definition-plugin fails to take advantage of that. The issue in a nutshell: I have this Dockerfile (excerpt):
ARG VERSION=latest
FROM repo-vp.development.ems:5000/emsys-adoptopenjdk11:${VERSION}
This is part of my declarative Jenkinsfile:
stage('Build') {
agent {
dockerfile {
filename 'Dockerfile'
additionalBuildArgs "--build-arg VERSION=jdk-11.0.2.9"
reuseNode true
}
}
steps {
(...)
}
}
This results in a failed build with
[JIRA] (JENKINS-56294) dockerfile: ARG in FROM breaks docker inspect
Title: Message Title
Christian Ciach updated an issue
Jenkins / JENKINS-56294
dockerfile: ARG in FROM breaks docker inspect
Change By:
Christian Ciach
Please note that there is already an issue with a very similar name regarding the docker-workflow plugin here: https://issues.jenkins-ci.org/browse/JENKINS-46105The issue actually has been fixed already at the docker-workflow plugin, but the pipeline-model-definition-plugin fails to take advantage of that.The issue in a nutshell:I have this Dockerfile (excerpt): {code:java}ARG VERSION=latestFROM repo-vp.development.ems:5000/emsys-adoptopenjdk11:${VERSION}{code} This is part of my declarative Jenkinsfile: {code:java}stage('Build') { agent { dockerfile { filename 'Dockerfile' additionalBuildArgs "--build-arg VERSION=jdk-11.0.2.9" reuseNode true} } steps {(...) }}{code} This results in a failed build with the following error log:{code:java}java.io.IOException: Cannot retrieve .Id from 'docker inspect repo-vp.development.ems:5000/emsys-adoptopenjdk11:${VERSION}' at org.jenkinsci.plugins.docker.workflow.client.DockerClient.inspectRequiredField(DockerClient.java:220) at org.jenkinsci.plugins.docker.workflow.FromFingerprintStep$Execution.run(FromFingerprintStep.java:133) at org.jenkinsci.plugins.docker.workflow.FromFingerprintStep$Execution.run(FromFingerprintStep.java:85) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:47) at hudson.security.ACL.impersonate(ACL.java:290) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:44) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)Finished: FAILURE{code}This has already been fixed by the docker-workflow plugin (see JENKINS-46105), but "pipeline-model-definition" has yet to take advantage of that.Please see this line in your plugin: [https://github.com/jenkinsci/pipeline-model-definition-plugin/blob/7502d14aa4db891302abf48a2c7de7c9ced97f95/pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/DockerPipelineFromDockerfileScript.groovy#L83]As you can see, you don't pass the new parameter "buildArgs" to the instance of `dockerFingerprintFrom`. See the setter here: [https://github.com/jenkinsci/docker-workflow-plugin/blob/dbeb7cf23961fdb5cbc495e8067bd42c56dcdfc5/src/main/java/org/jenkinsci/plugins/docker/workflow/FromFingerprintStep.java#L81]If you just pass the build-args to this step, the issue should be resolved.
[JIRA] (JENKINS-46105) Docker 17.05 ARG in FROM breaks docker inspect
Title: Message Title Christian Ciach commented on JENKINS-46105 Re: Docker 17.05 ARG in FROM breaks docker inspect EDIT: It looks like my issue is actually a bug in the "pipeline-model-definition-plugin". The plugin creates an instance of `FromFingerprintStep` (a class of this plugin), but fails to set the build-args (`FromFingerprintStep.setBuildArgs(..)`). See here: https://github.com/jenkinsci/pipeline-model-definition-plugin/blob/7502d14aa4db891302abf48a2c7de7c9ced97f95/pipeline-model-definition/src/main/resources/org/jenkinsci/plugins/pipeline/modeldefinition/agent/impl/DockerPipelineFromDockerfileScript.groovy#L83 Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-46105) Docker 17.05 ARG in FROM breaks docker inspect
Title: Message Title Christian Ciach commented on JENKINS-46105 Re: Docker 17.05 ARG in FROM breaks docker inspect I am confused: According to the comments here my example of the previous comment should work since docker-workflow 1.15. I am currently using 1.17, but it still doesn't work. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-46105) Docker 17.05 ARG in FROM breaks docker inspect
Title: Message Title
Christian Ciach commented on JENKINS-46105
Re: Docker 17.05 ARG in FROM breaks docker inspect
Probably also a dup of JENKINS-31507. I will repeat my comment here: Dockerfile:
ARG VERSION=latest
FROM repo-vp.development.ems:5000/emsys-adoptopenjdk11:$VERSION
Jenkinsfile (declarative):
agent {
dockerfile {
filename 'Dockerfile'
additionalBuildArgs "--build-arg VERSION=${env.JDK_VERSION}"
reuseNode true
}
}
Error log:
java.io.IOException: Cannot retrieve .Id from 'docker inspect repo-vp.development.ems:5000/emsys-adoptopenjdk11:$VERSION'
at org.jenkinsci.plugins.docker.workflow.client.DockerClient.inspectRequiredField(DockerClient.java:220)
at org.jenkinsci.plugins.docker.workflow.FromFingerprintStep$Execution.run(FromFingerprintStep.java:133)
at org.jenkinsci.plugins.docker.workflow.FromFingerprintStep$Execution.run(FromFingerprintStep.java:85)
at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:47)
at hudson.security.ACL.impersonate(ACL.java:290)
at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:44)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Finished: FAILURE
I haven't found a workaround yet.
Add Comment
[JIRA] (JENKINS-31507) docker.build throw IOExceptions with some sources
Title: Message Title
Christian Ciach commented on JENKINS-31507
Re: docker.build throw IOExceptions with some sources
Similar issue here. Dockerfile:
ARG VERSION=latest
FROM repo-vp.development.ems:5000/emsys-adoptopenjdk11:$VERSION
Jenkinsfile (declarative):
agent {
dockerfile {
filename 'Dockerfile'
additionalBuildArgs "--build-arg VERSION=${env.JDK_VERSION}"
reuseNode true
}
}
Error log:
java.io.IOException: Cannot retrieve .Id from 'docker inspect repo-vp.development.ems:5000/emsys-adoptopenjdk11:$VERSION'
at org.jenkinsci.plugins.docker.workflow.client.DockerClient.inspectRequiredField(DockerClient.java:220)
at org.jenkinsci.plugins.docker.workflow.FromFingerprintStep$Execution.run(FromFingerprintStep.java:133)
at org.jenkinsci.plugins.docker.workflow.FromFingerprintStep$Execution.run(FromFingerprintStep.java:85)
at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:47)
at hudson.security.ACL.impersonate(ACL.java:290)
at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:44)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Finished: FAILURE
I haven't found a workaround yet.
Add Comment
[JIRA] (JENKINS-56231) Suppress automatic SCM triggering is deprecated
Title: Message Title Christian Ciach edited a comment on JENKINS-56231 Re: Suppress automatic SCM triggering is deprecated I just noticed this, too. I cannot find a suitable alternative. Please at least adjust the help-text to tell users what to do instead. The main issue for me is the fact that Jenkins even triggers builds on branch-indexing when the build is parametrized. Of course, without parameters, these builds usually fail. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56231) Suppress automatic SCM triggering is deprecated
Title: Message Title Christian Ciach edited a comment on JENKINS-56231 Re: Suppress automatic SCM triggering is deprecated I just noticed this, too. I cannot find a suitable alternative. Please at least adjust the help-text to tell users what to do instead. The main issue for me is the fact that Jenkins even triggers builds on branch-indexing when the build is parametrized. Of course, without parameters, these builds usually fail. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56231) Suppress automatic SCM triggering is deprecated
Title: Message Title Christian Ciach commented on JENKINS-56231 Re: Suppress automatic SCM triggering is deprecated I just noticed this, too. I cannot find a suitable alternative. Please at least adjust the help-text to tell users what to do instead. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-55974) "No valid crumb was included in the request" when running behind nginx (since recent update)
Title: Message Title Christian Ciach updated JENKINS-55974 Jenkins / JENKINS-55974 "No valid crumb was included in the request" when running behind nginx (since recent update) Change By: Christian Ciach Status: Fixed but Unreleased Resolved Released As: 1.5 Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-55974) "No valid crumb was included in the request" when running behind nginx (since recent update)
Title: Message Title Christian Ciach updated JENKINS-55974 This is a duplicate of JENKINS-55698. The release of kerberos sso 1.5 fixed this issue for us. Jenkins / JENKINS-55974 "No valid crumb was included in the request" when running behind nginx (since recent update) Change By: Christian Ciach Status: Open Fixed but Unreleased Resolution: Duplicate Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-55974) "No valid crumb was included in the request" when running behind nginx (since recent update)
Title: Message Title Christian Ciach edited a comment on JENKINS-55974 Re: "No valid crumb was included in the request" when running behind nginx (since recent update) Also, Blue Ocean is broken when using Kerberos SSO. I always get the "Welcome to Jenkins - It's time to create your first Pipeline."-dialog in Blue Oceans Ocean , even though there are many existing projects and pipelines. Again, Blue Ocean works fine when not using Kerberos SSO (for example by using a private browser window). Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-55974) "No valid crumb was included in the request" when running behind nginx (since recent update)
Title: Message Title Christian Ciach commented on JENKINS-55974 Re: "No valid crumb was included in the request" when running behind nginx (since recent update) Also, Blue Ocean is broken when using Kerberos SSO. I always get the "Welcome to Jenkins - It's time to create your first Pipeline."-dialog in Blue Oceans, even though there are many existing projects and pipelines. Again, Blue Ocean works fine when not using Kerberos SSO (for example by using a private browser window). Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-55974) "No valid crumb was included in the request" when running behind nginx (since recent update)
Title: Message Title Christian Ciach updated an issue Jenkins / JENKINS-55974 "No valid crumb was included in the request" when running behind nginx (since recent update) Change By: Christian Ciach Environment: Jenkins 2.163-1 on CentOS 7 ; Kerberos SSO plugin 1 . Nginx 4; nginx as reverse proxy. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-55974) "No valid crumb was included in the request" when running behind nginx (since recent update)
Title: Message Title
Christian Ciach created an issue
Jenkins / JENKINS-55974
"No valid crumb was included in the request" when running behind nginx (since recent update)
Issue Type:
Bug
Assignee:
Tomas Westling
Components:
kerberos-sso-plugin
Created:
2019-02-05 12:49
Environment:
Jenkins 2.163-1 on CentOS 7. Nginx as reverse proxy.
Priority:
Major
Reporter:
Christian Ciach
This only happens when using the Kerberos SSO plugin! When I am visiting Jenkins using Firefox with a private window (meaning: Kerberos not active; login via Basic Auth instead), everything works fine. Since updating Jenkins from 2.159-1 to 2.163-1, I get the error message "No valid crumb was included in the request" on every POST request on Jenkins. Also, Jenkins warns me that my reverse proxy configuration is invalid (but again, only when using Kerberos!). I am pretty sure that my Nginx configuration is correct, according to the wiki. This is my configuration:
upstream jenkins {
keepalive 32;
server 127.0.0.1:8080;
}
server {
listen 443 ssl default_server;
server_name jenkins.development.ems;
ssl_certificate /root/jenkins.certs/jenkins.development.ems.chained.pem;
ssl_certificate_key /root/jenkins.certs/jenkins.development.ems.key;
root /data/nginx-root;
#pass through headers from Jenkins which are considered invalid by Nginx
ignore_invalid_headers off;
location /jenkins {
sendfile off;
proxy_pass http://jenkins;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_http_version 1.1;
proxy_set_header Host $host:$server_port;
prox
[JIRA] (JENKINS-44342) Karaoke does not resume after "scroll to bottom"
Title: Message Title Christian Ciach commented on JENKINS-44342 Re: Karaoke does not resume after "scroll to bottom" "Do not auto scroll to bottom as new log data is appended" is still an issue for me. This is very irritating, because our logs are extremely long and every time I try to scroll up (for example using the Home-key on the keyboard), it immediately scrolls all the way down again. Is this a known 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-42801) Can't access "include" or "list" in parallel test executor. Security exceptions thrown.
Title: Message Title
Christian Ciach edited a comment on JENKINS-42801
Re: Can't access "include" or "list" in parallel test executor. Security exceptions thrown.
Actually, I don't fully understand why it worked for me ever before. I do not use inclusions (and never have, I checked our SCM), so, according to {{SplitStep.Execution.run()}} I should have gotten {{List>}} as the return type, not {{List}}.My best guess is that {{split.list.join("\n")}} worked before for me before , because Jenkins allowed me to access the private field "list" inside "UnmodifiableList". Long story short: When not letting the plugin generate inclusions, the return type of {{splitTests}} is {{List>}} instead of {{List}}. If this is not documented, it should have been :)
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-42801) Can't access "include" or "list" in parallel test executor. Security exceptions thrown.
Title: Message Title
Christian Ciach edited a comment on JENKINS-42801
Re: Can't access "include" or "list" in parallel test executor. Security exceptions thrown.
{{ Actually, I don't fully understand why it worked for me ever before. I do not use inclusions (and never have, I checked our SCM), so, according to {{ SplitStep.Execution.run() }} I should have gotten {{ List> }} as the return type, not {{ List . }} . My best guess is that " {{ split.list.join("\n") " }} worked before for me, because Jenkins allowed me to access the private field "list" inside "UnmodifiableList". Long story short: When not letting the plugin generate inclusions, the return type of " {{ splitTests " }} is " {{ List> " }} instead of "List< {{ List< InclusionExclusionPattern> " }} . If this is not documented, it should have been .}} :)
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-42801) Can't access "include" or "list" in parallel test executor. Security exceptions thrown.
Title: Message Title
Christian Ciach commented on JENKINS-42801
Re: Can't access "include" or "list" in parallel test executor. Security exceptions thrown.
Actually, I don't fully understand why it worked for me ever before. I do not use inclusions (and never have, I checked our SCM), so, according to SplitStep.Execution.run() I should have gotten List> as the return type, not List. My best guess is that "split.list.join("\n")" worked before for me, because Jenkins allowed me to access the private field "list" inside "UnmodifiableList". Long story short: When not letting the plugin generate inclusions, the return type of "splitTests" is "List>" instead of "List". If this is not documented, it should have been.
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-42801) Can't access "include" or "list" in parallel test executor. Security exceptions thrown.
Title: Message Title
Christian Ciach commented on JENKINS-42801
Re: Can't access "include" or "list" in parallel test executor. Security exceptions thrown.
After updating Jenkins and some plugins to the current version today, I encounter this issue, too. I didn't change anything in my Jenkinsfile. Part of the stacktrace is:
org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: No such field found: field java.lang.String list at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.unclassifiedField(SandboxInterceptor.java:397)
Trying to debug this, i used this snipped inside my Jenkinsfile: def splits = splitTests parallelism: count(6) echo "Class of splits is ${splits.class}" for (int i = 0; i < splits.size(); i++) { def num = i def split = splits.get(num) echo "Class of split ${num} is ${split.class}" {{ }}} I expected the list elements to be of type InclusionExclusionPattern, but instead the output is this:
[Pipeline] echo Class of splits is class java.util.ArrayList [Pipeline] echo Class of split 0 is class java.util.Collections$UnmodifiableRandomAccessList [Pipeline] echo Class of split 1 is class java.util.Collections$UnmodifiableRandomAccessList [Pipeline] echo Class of split 2 is class java.util.Collections$UnmodifiableRandomAccessList [Pipeline] echo Class of split 3 is class java.util.Collections$UnmodifiableRandomAccessList [Pipeline] echo Class of split 4 is class java.util.Collections$UnmodifiableRandomAccessList [Pipeline] echo Class of split 5 is class java.util.Collections$UnmodifiableRandomAccessList
In fact, these are lists of Strings. I have no idea how this could happen.
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
[JIRA] (JENKINS-49468) Pipeline view only able to select the top-most of the in-progress parallel nodes
Title: Message Title Christian Ciach edited a comment on JENKINS-49468 Re: Pipeline view only able to select the top-most of the in-progress parallel nodes This issue seems to pop up again from time to time. Related issues are - JENKINS-43747 - and - JENKINS-42312 - . Edit: Seems to be fixed alread: JENKINS-49272 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-49468) Pipeline view only able to select the top-most of the in-progress parallel nodes
Title: Message Title Christian Ciach edited a comment on JENKINS-49468 Re: Pipeline view only able to select the top-most of the in-progress parallel nodes This issue seems to pop up again from time to time. Related issues are - - JENKINS-43747- - and - - JENKINS-42312- - .Edit: Seems to be fixed alread already : - JENKINS-49272 - 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-49468) Pipeline view only able to select the top-most of the in-progress parallel nodes
Title: Message Title Christian Ciach commented on JENKINS-49468 Re: Pipeline view only able to select the top-most of the in-progress parallel nodes This issue seems to pop up again from time to time. Related issues are JENKINS-43747 and JENKINS-42312. 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-49468) Pipeline view only able to select the top-most of the in-progress parallel nodes
Title: Message Title Christian Ciach edited a comment on JENKINS-49468 Re: Pipeline view only able to select the top-most of the in-progress parallel nodes Can confirm. It should be noted that this issue is only with pipelines that are currently in progress. If the pipeline has finished, I can select and view the data of all parallel nodes just fine. [~retronym], you accidentally linked to this issue, instead of a related 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-49468) Pipeline view only able to select the top-most of the in-progress parallel nodes
Title: Message Title Christian Ciach commented on JENKINS-49468 Re: Pipeline view only able to select the top-most of the in-progress parallel nodes Can confirm. It should be noted that this issue is only with pipelines that are currently in progress. If the pipeline has finished, I can select and view the data of all parallel nodes just fine. 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.
