[JIRA] [cli] (JENKINS-22346) jenkins cli command with key fails with - java.io.EOFException
Samu Wikstedt commented on JENKINS-22346 jenkins cli command with key fails with - java.io.EOFException Agreed that ssh-key based authentication for jenkins-cli is broken somewhere between LTS versions 1.554.2 and 1.565.2 See the small test below: 42 root @ x /home/jenkins ls |grep jenkins-cli jenkins-cli.jar_1.532.2 jenkins-cli.jar_1.554.2 jenkins-cli.jar_1.565.2 43 root @ xx /home/jenkins sudo -u jenkins java -jar jenkins-cli.jar_1.532.2 -s http://..:8080 -i /var/lib/jenkins/.ssh/id_rsa.pub version 1.565.2 44 root @ xx /home/jenkins sudo -u jenkins java -jar jenkins-cli.jar_1.554.2 -s http://xxx.xxx.:8080 -i /var/lib/jenkins/.ssh/id_rsa.pub version 1.565.2 45 root @ XXX /home/jenkins sudo -u jenkins java -jar jenkins-cli.jar_1.565.2 -s http://xxx.xxx.:8080 -i /var/lib/jenkins/.ssh/id_rsa.pub version Exception in thread "main" java.io.IOException: Invalid PEM structure, '-BEGIN...' missing at com.trilead.ssh2.crypto.PEMDecoder.parsePEM(PEMDecoder.java:138) at com.trilead.ssh2.crypto.PEMDecoder.decode(PEMDecoder.java:313) at hudson.cli.PrivateKeyProvider.loadKey(PrivateKeyProvider.java:143) at hudson.cli.PrivateKeyProvider.loadKey(PrivateKeyProvider.java:126) at hudson.cli.PrivateKeyProvider.readFrom(PrivateKeyProvider.java:107) at hudson.cli.CLI._main(CLI.java:428) at hudson.cli.CLI.main(CLI.java:382) 46 root @ /home/jenkins This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [copyartifact] (JENKINS-22480) option to check file checksums after copying artfacts
Samu Wikstedt commented on JENKINS-22480 option to check file checksums after copying artfacts It is definitely problem in Win7 file system or it's java implementation. Checksum would have probably help, but not necessarily because of the checksum itself, but because checking it causes some delay to project execution... Anyway, our system seems to have slowed down enough, so the problem is practically gone for now. And whenever possible, we are moving to using linux instead of windows, and this is strictly Win7 specific problem. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [copyartifact] (JENKINS-22480) copyartifact plugin does not properly check files it has transferred
Samu Wikstedt created JENKINS-22480 copyartifact plugin does not properly check files it has transferred Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: copyartifact Created: 03/Apr/14 6:21 AM Description: We have following kind of scenario: Artifacts (text files containing SVN revision info) are transferred to matrix project(s), which are executed on Win7 slave nodes that are virtualmachines. Project read version info files as system variables and uses variable when executing svn checkout from command line Problem: Occasionally (not always) variable is empty -because file is still empty while it is read, when checking file content afterwards from workspace, content is OK. I presume that root cause is file-system buffer etc. Workaround: We added step that delays file reading couple of seconds, and problem was gone. Suggesting: Add file checksum test to copyartifacts plugin, or some other test that verifies that files really are written to file-system and can be used before plugin finishes its task. Filing this as a bug, but it might be more improvement idea. Change status how you feel appropriate. Environment: RHEL 6.3 os.arch amd64 os.name Linux os.version 2.6.32-279.el6.x86_64 java.runtime.name OpenJDK Runtime Environment java.runtime.version 1.6.0_24-b24 Jenkins 1.509.4 Fix Versions: current Project: Jenkins Priority: Major Reporter: Samu Wikstedt This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [throttle-concurrents] (JENKINS-21830) Throttle-concurrents -plugin do not recognise new slave nodes generated after build are on queue
Samu Wikstedt created JENKINS-21830 Throttle-concurrents -plugin do not recognise new slave nodes generated after build are on queue Issue Type: Bug Affects Versions: current Assignee: abayer Components: throttle-concurrents Created: 17/Feb/14 12:18 PM Description: Situation: Jenkins project uses matrix build (dynamic axis) to create massive job load Jobs are put on the queue since there is not enough executors on master and slave nodes separate load balancer starts new slave nodes from cloud-cluster, which are connected to master with help of swarm-plugin. throttle-plugin allows jobs from queue to be run only on slaves that were existing before jobs were launched. If throttle plugin is removed, all new slave nodes are utilized immediately. On situation described, throttle plugin also seems to stuck jenkins GUI. (After removal of throttle, GUI doesn't get stuck ). I have no idea what kind of logs/trace I should focus on, so feel free to ask those if needed. Environment: Linux (RHEL)/64 bit jenkins: 1.532.1 (LTS) throttle: 1.8.1 Project: Jenkins Labels: plugin jenkins Priority: Major Reporter: Samu Wikstedt This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [matrix] (JENKINS-16521) Multi-Project Throttle Categories don't work with Matrix jobs
Samu Wikstedt commented on JENKINS-16521 Multi-Project Throttle Categories dont work with Matrix jobs Hi, is this behaviour somehow related to issue we've see lately with matrix jobs and throttle-plugin: throttle plugin do not recognize slave nodes that has been added after the matrix jobs has been gone to queue. Resulting those jobs going to slave nodes that has been there before job launch and new nodes doing nothing. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [scm-sync-configuration] (JENKINS-18036) scm-sync plugin ends up in commit-conflicts and eventually eats most of available CPU time
Samu Wikstedt created JENKINS-18036 scm-sync plugin ends up in commit-conflicts and eventually eats most of available CPU time Issue Type: Bug Affects Versions: current Assignee: Frédéric Camblor Components: scm-sync-configuration Created: 22/May/13 6:44 AM Description: On a (relatively big?) jenkins installation (~640 jobs and ~2200 folders and subfolders under jobs/ folder) it seems that scm-sync gets confused whether add or just commit config files and ends up in conflict situation. Besides of a size, this jenkins has almost zero idle time, meaning: there is allways some project running. following logs are repeated: tail /var/log/jenkins/jenkins.log SEVERE: checkinFiles Problem during SCM commit : svn: E155004: Commit failed (details follow): svn: E155004: There are unfinished work items in '/var/lib/jenkins/scm-sync-configuration/checkoutConfiguration'; run 'svn cleanup' first. May 21, 2013 10:29:49 AM hudson.plugins.scm_sync_configuration.ScmSyncConfigurationBusiness processCommitsQueue SEVERE: Error while processing commit queue : Error while checking in file to scm repository INFO SVN commit directory: /var/lib/jenkins/scm-sync-configuration/checkoutConfiguration May 21, 2013 10:29:49 AM hudson.plugins.scm_sync_configuration.SCMManipulator checkinFiles SEVERE: checkinFiles Problem during SCM commit : svn: E155004: Commit failed (details follow): svn: E155004: There are unfinished work items in '/var/lib/jenkins/scm-sync-configuration/checkoutConfiguration'; run 'svn cleanup' first. May 21, 2013 10:29:49 AM hudson.plugins.scm_sync_configuration.ScmSyncConfigurationBusiness processCommitsQueue SEVERE: Error while processing commit queue : Error while checking in file to scm repository After day or two jenkins' java prosess takes all available CPU power and practically forces to reboot jenkins. Feel free to ask more detailed logs if necessary. Environment: - OS platform Ubuntu-64 12.04 LTS - Jenkins 1.509.1 (LTS) Project: Jenkins Priority: Major Reporter: Samu Wikstedt This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [scm-sync-configuration] (JENKINS-17946) Include a list of plugins installed
Samu Wikstedt commented on JENKINS-17946 Include a list of plugins installed You are right about the plugin versions issue; Following LTS jenkins update cycle, is nicely working solution for us. But true, that might not be the case in all users. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [scm-sync-configuration] (JENKINS-17946) Include a list of plugins installed
Samu Wikstedt resolved JENKINS-17946 as Not A Defect Include a list of plugins installed BAcking up running jenkins is highly dependent on the matter how jenkins maintainer want's to back it up. --- It's better to leave needed plugin list generation to one own solution(s) that meets ones requirements. Change By: Samu Wikstedt (21/May/13 6:49 AM) Status: Open Resolved Resolution: NotADefect This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [scm-sync-configuration] (JENKINS-17946) Include a list of plugins installed
Samu Wikstedt
commented on JENKINS-17946
Include a list of plugins installed
I guess responsibility of scm-sync-configuration depends on the point of view: Meaning, if purpose is to have backup stored in a safe place, which can be restored after total disaster (for example disk failure, stolen hardware, fire ...) then list of installed plugins is needed. My experienses are that if you try to restore a xml files that have configuration of plugins not currently installed, Jenkins gets quite confused.
If the purpose is just to have SCM repository where old changes in working jenkins configuration can be fetched if needed, this plugin works just fine. And I am not intended to start a debate of the purpose of the plugin. After all it is great tool for my purposes already. So, I am just suggesting widening the scope of the plugin since I think that it could be done quite easily - However, since my java programming skills are severely limited , I might be mistaken on that one
Since I do lack java programming skills, developing plugin is out of my scope. However I do have done a Jenkins restore successfully with method that is more simple that your way of getting plugin list... Now I'm just wondering whether I had more simple plugins than you have had... So what information is lost with method described below:
Prerequisite are:
Jenkins installation, which have configuration backed up with scm-sync-configuration.
List of installed plugins is created with help of jenkins-cli and stripped to more simple list and included to backup:
java -jar jenkins-cli.jar -s http://yourjenkinsurl:8080/ list-plugins plugins.txt
awk '{print $1}' plugins.txt plugins_tripped.txt
Output is a simple list which have simple list of plugin names.
The actual restoring config has these steps:
have new HW-platform with working OS for your jenkins
install fresh jenkins on top of that
Install all plugins from jenkins update site, use the plugins-list from backup:
cat plugins_tripped.txt | xargs java -jar jenkins-cli.jar -s http://yourjenkinsurl:8080/ install-plugin
Shut down jenkins, do svn checkout (or GIT pull) to a temporary folder and copy everything to jenkins home folder, start jenkins and you should have working jenkins again up and running.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [scm-sync-configuration] (JENKINS-17946) Include a list of plugins installed
Samu Wikstedt created JENKINS-17946 Include a list of plugins installed Issue Type: Improvement Assignee: Frédéric Camblor Components: scm-sync-configuration Created: 14/May/13 11:48 AM Description: SCMsync is great plugin for having backup in safe place, but if you ever need to restore configuration after total disaster, it lacks information of plugins that were installed. It would be good to have this plugin to create a list of plugins installed to jenkins and store it to svn/git with other config data. Project: Jenkins Priority: Major Reporter: Samu Wikstedt This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-14839) 'Abort the build if it's stuck' does not work when cloud node has start up problmes
Samu Wikstedt created JENKINS-14839 Abort the build if its stuck does not work when cloud node has start up problmes Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: core Created: 17/Aug/12 7:13 AM Description: When using EC cloud nodes to execute projects, the option 'Abort the build if it's stuck' does not work for it's original purpose: Making sure that in case of major problem(s) during project execution, project will be put to 'failed' state after certain time: Project's time-count will start after cloud node has been started up, if problem is with starting the EC2 -node, time is never run out, meaning: project won't fail -ever. Could the time-count be started immediately when project starts, regardless if project needs to start cloud node? Project: Jenkins Priority: Minor Reporter: Samu Wikstedt This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14651) ProjectsBuild Time Trend is shows incorrect node information if test are executed on ec2 cloud node
Samu Wikstedt created JENKINS-14651 ProjectsBuild Time Trend is shows incorrect node information if test are executed on ec2 cloud node Issue Type: Bug Assignee: Kohsuke Kawaguchi Components: ec2 Created: 01/Aug/12 10:14 AM Description: How to reproduce: Create certain test(s) that are executed on ec2 clould node, which is to be shutdown afterwards if no other project activity is happening Let run couple of times so that nodes are being start and shutdown. Check project's 'Trend' 'Build Time Trend' -list shows projects in the past as being executed on master node, however, in the graph, correct slave-node's name is shown. Project: Jenkins Priority: Minor Reporter: Samu Wikstedt This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13600) Cannot access JNLP URL with apiToken after upgrade to 1.461
[ https://issues.jenkins-ci.org/browse/JENKINS-13600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162312#comment-162312 ] Samu Wikstedt commented on JENKINS-13600: - Hi, is this same bug affecting API functionality as a whole? Not just when using openID plugin? We are using LDAP authentication and have experiencing problems after After upgrading to 1.461, and upgrading to 1.462 didn't fix this. (parametrized)Jenkins projects are builded trough API like this: swiksted@:~$ wget --no-proxy --auth-no-challenge --http-user=swiksted --http-password=users_api_token http://../job/projectname/buildWithParameters? --post-data=param=valueanother_param=another_value --2012-05-02 10:25:14-- http://xxx.xxx.xxx/job/project_name/buildWithParameters? Resolving xxx.xxx.xxx... xxx.xxx.xxx.xxx Connecting to xxx.xxx.xxx|xxx.xxx.xxx.xxx|80 failed: Connection refused. Cannot access JNLP URL with apiToken after upgrade to 1.461 --- Key: JENKINS-13600 URL: https://issues.jenkins-ci.org/browse/JENKINS-13600 Project: Jenkins Issue Type: Bug Components: core Reporter: Sidnei da Silva Accessing the JNLP URL on an OpenID-protected instance does not work anymore after upgrading to 1.461. Reverting to 1.459 makes it work again. Error with 1.461: Exception: Unexpected authentication type: org.acegisecurity.providers.UsernamePasswordAuthenticationToken@9f6d50cd: Username: hal; Password: [PROTECTED]; Authenticated: false; Details: org.acegisecurity.ui.WebAuthenticationDetails@957e: RemoteIpAddress: 127.0.0.1; SessionId: null; Not granted any authorities To test: curl -kinsecure -u user:apitoken https://localhost/computer/computer-name/slave-agent.jnlp -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
