[JIRA] [jclouds-jenkins] (JENKINS-19935) Instances on EC2 don't get random suffix
John Engelman commented on JENKINS-19935 Instances on EC2 dont get random suffix Trying this with Jclouds-Jenkins-2.9-SNAPSHOT (running with jclouds-1.8) and this still doesn't work. The instance is created with the name of the EC2 template. Subsequent slaves are started and seemed to be configured, but never join into Jenkins as slaves. 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] [jclouds-jenkins] (JENKINS-19935) Instances on EC2 don't get random suffix
John Engelman commented on JENKINS-19935 Instances on EC2 dont get random suffix The problem is here: https://github.com/jenkinsci/jclouds-plugin/blob/master/jclouds-plugin/src/main/java/jenkins/plugins/jclouds/compute/JCloudsSlave.java#L83 That sets the Node name to be the metadata.getName() which is just the template name. I've fixed for myself by using a custom build that changes that line to use: metaData.getName() + "-" + metaData.getProviderId() This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-11757) Editing a slave configuration producse Error 500 with JSONObject[name] not found
John Engelman commented on JENKINS-11757 Editing a slave configuration producse Error 500 with JSONObject[name] not found It’s definitely the same error that occurs on the JClouds plugin. Haven’t tried the EC2 plugin. Could be that the name isn’t being sent to the view to be bound so that it can be sent back. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-11757) Editing a slave configuration producse Error 500 with JSONObject[name] not found
John Engelman commented on JENKINS-11757 Editing a slave configuration producse Error 500 with JSONObject[name] not found The problem is here: https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/Computer.java#L1189-L1190 But the form in the JClouds plugin doesn't bind a value to the "name" property: https://github.com/jenkinsci/jclouds-plugin/blob/master/jclouds-plugin/src/main/resources/jenkins/plugins/jclouds/compute/JCloudsComputer/configure.jelly I also never see the "instanceId" property have a value in it whenever I boot an instance up. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-11757) Editing a slave configuration producse Error 500 with JSONObject[name] not found
John Engelman commented on JENKINS-11757 Editing a slave configuration producse Error 500 with JSONObject[name] not found Still occurs in: Jenkins: 1.571 JClouds: 2.8 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] [cli] (JENKINS-22346) jenkins cli command with key fails with - java.io.EOFException
John Engelman commented on JENKINS-22346 jenkins cli command with key fails with - java.io.EOFException I think the problem is this line: https://github.com/jenkinsci/jenkins/blob/0e339d7a454df119995b896eea14f09a099f99b5/core/src/main/java/hudson/model/User.java#L264 which was introduced in https://github.com/jenkinsci/jenkins/commit/0e339d7a454df119995b896eea14f09a099f99b5. The User object is now re-throwing the UsernameNotFoundException instead of eating it and failing through to the UsernamePasswordAuthenticationToken. The Active Directory plugin throws this exception when the user is not found in AD environment: https://github.com/jenkinsci/active-directory-plugin/blob/master/src/main/java/hudson/plugins/active_directory/ActiveDirectoryAuthenticationProvider.java#L110 So the question is, what's the correct solution? Should the Active Directory plugin be throwing a different exception in this instance (perhaps the UserMayOrMayNotExistException)? Or should Jenkins do something different when it encounters the UsernameNotFoundException? 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] [cli] (JENKINS-22346) jenkins cli command with key fails with - java.io.EOFException
John Engelman commented on JENKINS-22346 jenkins cli command with key fails with - java.io.EOFException Nevermind...This doesn't appear related. The CLI fails regardless if the AD plugin is installed or not. 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] [cli] (JENKINS-22346) jenkins cli command with key fails with - java.io.EOFException
John Engelman commented on JENKINS-22346 jenkins cli command with key fails with - java.io.EOFException Ok, so I pulled the latest code and did some testing and this is what I've found. It is related to the change in User.java -https://github.com/jenkinsci/jenkins/blob/0e339d7a454df119995b896eea14f09a099f99b5/core/src/main/java/hudson/model/User.java#L264 That line re-throws the UsernameNotFoundException. Scenario #1 Security is not enabled. User passes a key to jenkins-cli -i key-file = returns an EOFException. Commented out throw UsernameNotFoundException in User.java. Test #1 - pass key for user defined when security was enabled = Jenkins reports the user as authenticated Test #2 - pass random private key = Jenkins reports Authentication failed. Scenario #2 AD security is enabled. User passes a key for a user defined in Jenkin's user database = returns an EOFException. Change the AD plugin to throw a UserMayOrMayNotExistException. Test #1 - pass key for user defined in AD = Jenkins reports the user as authenticated. Test #2 - pass key for user defined in Jenkins Database = Jenkins reports the user as authenticated. Test #3 - pass random private key = Jenkins reports auth failed. I think the issue here is that for Scenario #1, the SecurityRealm.None implementation throws a UsernameNotFoundException for loadByUsername(id). This is no handled differently. I suspect the answer is that it should throw s UserMayOrMayNotExistException instead. This would be the same problem with the AD plugin...it throws a UsernameNotFoundException if the user doesn't exist in AD, that exception percolates up and causes the EOF. Instead, the plugin should throw UserMayOrMayNotExistException, so Jenkins falls back. 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] [cli] (JENKINS-22346) jenkins cli command with key fails with - java.io.EOFException
John Engelman commented on JENKINS-22346 jenkins cli command with key fails with - java.io.EOFException Is this still an issue with the latest versions of 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] [gradle] (JENKINS-21653) Gradle build command not working as Gradle version is unavailable for selection in Configure
John Engelman commented on JENKINS-21653 Gradle build command not working as Gradle version is unavailable for selection in Configure You'll need to configure a Gradle installation under Jenkins | Manage Jenkins | Gradle. There you can set up different installations to either installed locations on the file system or have Jenkins automatically install it from gradle.org. 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] [openid] (JENKINS-14843) OpenID SSO should use POST to submit details to google apps endpoint
John Engelman commented on JENKINS-14843 OpenID SSO should use POST to submit details to google apps endpoint Just tried to disable using the property and there is a missing '.' in the code that looks up the property. Using the malformed -Dhudson.plugins.openid.impl.TeamsExtensiondisable=true does work though. 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] [violations] (JENKINS-17722) Violations Codenarc Parser doesn't respect SourceDirectory XML tag
John Engelman created JENKINS-17722 Violations Codenarc Parser doesnt respect SourceDirectory XML tag Issue Type: Bug Assignee: peterkittreilly Components: violations Created: 23/Apr/13 3:53 PM Description: When running a Codenarc report against a subdirectory (i.e. a Gradle subproject), Codenarc generates a report where the Package path is relative to the subproject but includes a SourceDirectory tag to indicate path of the subproject relative to the root project. The CodenarcParser doesnt' respect the SourceDirectory tag when generating the file model so violations aren't rendered appropriately to the view. The violation is displayed on the summary, but clicking the link brings you to an empty page. Project: Jenkins Priority: Major Reporter: John Engelman 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] [violations] (JENKINS-17722) Violations Codenarc Parser doesn't respect SourceDirectory XML tag
John Engelman commented on JENKINS-17722 Violations Codenarc Parser doesnt respect SourceDirectory XML tag I've created a pull request to add the SourceDirectory parsing to the CodenarcParser.java file: https://github.com/jenkinsci/violations-plugin/pull/29 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-14345) Grails wrapper doesn't respect Project Base Directory
John Engelman
reopened JENKINS-14345
Grails wrapper doesnt respect Project Base Directory
This change broke the use of the $WORKSPACE variable inside grails.work.dir.
set grails.work.dir = ${WORKSPACE}/.grails, results in this error:
FATAL: No such property: WORKSPACE for class: Script1
groovy.lang.MissingPropertyException: No such property: WORKSPACE for class: Script1
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:50)
at org.codehaus.groovy.runtime.callsite.PogoGetPropertySite.getProperty(PogoGetPropertySite.java:49)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGroovyObjectGetProperty(AbstractCallSite.java:231)
at Script1.run(Script1.groovy:1)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:580)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:618)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:589)
at com.g2one.hudson.grails.GrailsBuilder.evalTarget(GrailsBuilder.java:262)
at com.g2one.hudson.grails.GrailsBuilder.perform(GrailsBuilder.java:191)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:717)
at hudson.model.Build$BuildExecution.build(Build.java:199)
at hudson.model.Build$BuildExecution.doRun(Build.java:160)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1488)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:236)
Change By:
John Engelman
(20/Jul/12 2:08 PM)
Resolution:
Fixed
Status:
Resolved
Reopened
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-13174) Stop changeset tags from being counted as a change in Mercurial Plugin polling
[
https://issues.jenkins-ci.org/browse/JENKINS-13174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Engelman reopened JENKINS-13174:
-
The fix that was implemented for this breaks sub-repository support in the
plugin.
The patch ignores all files that start with '.hg'
{code}
if (changedFile.startsWith(.hg)) { // .hgignore, .hgtags, ...
{code}
However, this will excludes files such as .hgsub and .hgsubstate that when
changed, should be triggering a build.
Stop changeset tags from being counted as a change in Mercurial Plugin polling
--
Key: JENKINS-13174
URL: https://issues.jenkins-ci.org/browse/JENKINS-13174
Project: Jenkins
Issue Type: Bug
Components: mercurial
Affects Versions: current
Reporter: Neil Kay
Assignee: jglick
We have the slave build machines polling Mercurial repositories, using the
Mercurial plugin, to trigger builds.
During the Jenkins job, we create and push a tag changeset as part of the
build process.
This tag changeset is detected by polling and causing an infinite loop of
builds.
I've looked into other options, I notice the notice away from polling to be
more push activated, which sounds good, but it seems this still relies on
polling to detect what has changed, so it seems this would still be a problem.
The other thing that sounded like it may help was modules in the Mercurial
plugin, but this is a huge change to move lots of repositories to put
everything except the hgtags file into a sub folder and then specify that sub
folder as a module.
If tag changesets were ignorred by polling, similar to a change that was made
to ignore merge changesets, all would be good in the world :)
--
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
[JIRA] (JENKINS-13174) Stop changeset tags from being counted as a change in Mercurial Plugin polling
[ https://issues.jenkins-ci.org/browse/JENKINS-13174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163499#comment-163499 ] John Engelman edited comment on JENKINS-13174 at 6/5/12 2:04 AM: - @jglick I saw that JIRA ticket for adding sub-repo support and just as an FYI, we've been using Jenkins with a project that has 3 sub-repositories in it just fine for the last year. We haven't had any issues with it and I believe the Mercurial repository sharing and caching works out-of-the box. Not sure what else would be left to add for support. Thanks for getting a patch in so quick. Appreciate it. was (Author: johnengelman): @jglick I saw that JIRA ticket for adding sub-repo support and just as an FYI, we've been using Jenkins with a project that has 3 sub-repositories in it just fine for the last year. We haven't had any issues with it and I believe the Mercurial repository sharing and caching works out-of-the box. Not sure what else would be left to add for support. Thanks for getting a patch in though so quick. Appreciate it. Stop changeset tags from being counted as a change in Mercurial Plugin polling -- Key: JENKINS-13174 URL: https://issues.jenkins-ci.org/browse/JENKINS-13174 Project: Jenkins Issue Type: Bug Components: mercurial Affects Versions: current Reporter: Neil Kay Assignee: jglick We have the slave build machines polling Mercurial repositories, using the Mercurial plugin, to trigger builds. During the Jenkins job, we create and push a tag changeset as part of the build process. This tag changeset is detected by polling and causing an infinite loop of builds. I've looked into other options, I notice the notice away from polling to be more push activated, which sounds good, but it seems this still relies on polling to detect what has changed, so it seems this would still be a problem. The other thing that sounded like it may help was modules in the Mercurial plugin, but this is a huge change to move lots of repositories to put everything except the hgtags file into a sub folder and then specify that sub folder as a module. If tag changesets were ignorred by polling, similar to a change that was made to ignore merge changesets, all would be good in the world :) -- 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
[JIRA] (JENKINS-13174) Stop changeset tags from being counted as a change in Mercurial Plugin polling
[ https://issues.jenkins-ci.org/browse/JENKINS-13174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163499#comment-163499 ] John Engelman commented on JENKINS-13174: - @jglick I saw that JIRA ticket for adding sub-repo support and just as an FYI, we've been using Jenkins with a project that has 3 sub-repositories in it just fine for the last year. We haven't had any issues with it and I believe the Mercurial repository sharing and caching works out-of-the box. Not sure what else would be left to add for support. Thanks for getting a patch in though so quick. Appreciate it. Stop changeset tags from being counted as a change in Mercurial Plugin polling -- Key: JENKINS-13174 URL: https://issues.jenkins-ci.org/browse/JENKINS-13174 Project: Jenkins Issue Type: Bug Components: mercurial Affects Versions: current Reporter: Neil Kay Assignee: jglick We have the slave build machines polling Mercurial repositories, using the Mercurial plugin, to trigger builds. During the Jenkins job, we create and push a tag changeset as part of the build process. This tag changeset is detected by polling and causing an infinite loop of builds. I've looked into other options, I notice the notice away from polling to be more push activated, which sounds good, but it seems this still relies on polling to detect what has changed, so it seems this would still be a problem. The other thing that sounded like it may help was modules in the Mercurial plugin, but this is a huge change to move lots of repositories to put everything except the hgtags file into a sub folder and then specify that sub folder as a module. If tag changesets were ignorred by polling, similar to a change that was made to ignore merge changesets, all would be good in the world :) -- 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
