[JIRA] [promoted-builds] (JENKINS-18286) Inject the promoting job's JOB_NAME and BUILD_NUMBER into target env.
Thomas Lehmann created JENKINS-18286 Inject the promoting jobs JOB_NAME and BUILD_NUMBER into target env. Issue Type: Improvement Assignee: Unassigned Components: promoted-builds Created: 11/Jun/13 10:24 AM Description: The target job should pre-define variables containing the job name and build number of the Job that causes the build. Example: Upstream #3 promotes Downstream Then in Downstream I have JENKINS_PROMOTING_JOB_NAME="Upstream" and JENKINS_PROMOTING_BUILD_NUMBER="3" defined This is useful where the downstream promotion should copy artifacts from the upstream project. The upstream's job name can be manually configured for the downstream job, but this is not possible when multiple upstream jobs should be able to trigger one downstream job. Currently I workaround this using the Jenkins CLI within a shell excecuting promotion where I trigger parameterized builds. But this is times slower than a "execute shell" promotion. Project: Jenkins Labels: downstream variables promotion upstream promoted jobname environment buildnumber inject predefined implicit Priority: Major Reporter: Thomas Lehmann 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] [promoted-builds] (JENKINS-18286) Inject the upstream's job's JOB_NAME and BUILD_NUMBER into downstream env.
Thomas Lehmann updated JENKINS-18286 Inject the upstreams jobs JOB_NAME and BUILD_NUMBER into downstream env. Change By: Thomas Lehmann (11/Jun/13 10:31 AM) Summary: Injectthe promoting upstreams jobsJOB_NAMEandBUILD_NUMBERinto target downstream env. 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-15947) Promoted builds *list* should also be requestable via REST
Thomas Lehmann commented on JENKINS-15947 Promoted builds *list* should also be requestable via REST Could please tell some one if this bug will be fixed (or if it will be rejected) (regardless of the time it's being started or even resolved)? 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-15947) Promoted builds *list* should also be requestable via REST
Thomas Lehmann created JENKINS-15947 Promoted builds *list* should also be requestable via REST Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: promoted-builds Created: 27/Nov/12 9:26 PM Description: The promoted builds plugin provides an API for a promotion but not for the list of promotions. Available: host/jenkins/job/project/build number/promotion/promotion name/promotionBuild/promotion number/api/xml Should be available: host/jenkins/job/project/build number/promotion/api/xml host/jenkins/job/project/build number/promotion/promotion name/promotionBuild/api/xml Environment: RedHat 6, Debian Stable Linux, Sun Java 1.7 JDK, Jenkins 1.491 Project: Jenkins Labels: xml promoted plugin api json build Priority: Major Reporter: Thomas Lehmann 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-13788) Git user and Crowd 2 authenticated user should be equal (one User-Id)
Thomas Lehmann commented on JENKINS-13788 Git user and Crowd 2 authenticated user should be equal (one User-Id) Sorry, what do you mean with "the user generated out of the Git user"? Regardless of whether using the Crowd plugin or not, the Git plugin (or Jenkins) create users (in Filesystem) out of the users found in the Git history. I can see this because there were Git-identities named "logonname logonn...@somedevelopershost.acme.com" when a user forgot to set its identity in the Git config. Now you've lost me... How do you "generate" users/usernames? Let's not say users/usernames are generated but "persons". One users will appear multiple (at least two) times in the Persons page (this is what I've called users before). One user is reflected by the Crowd user, another by the developers git identity. My guess is that the problem is in the Crowd plugin and not in the Git plugin. I don't think this is related to the Git nor the Crowd plugin but Jenkins. Because there are multiple authentication and versioning plugins they shouldn't care about each other to solve this issue. Jenkins should provide a mechanism to associate a VCS identity with Jenkins identity (optionally provided by an authentication plugin). 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-13788) Git user and Crowd 2 authenticated user should be equal (one User-Id)
Thomas Lehmann edited a comment on JENKINS-13788 Git user and Crowd 2 authenticated user should be equal (one User-Id) Sorry, what do you mean with "the user generated out of the Git user"? Regardless of whether using the Crowd plugin or not, the Git plugin (or Jenkins) create users (in Filesystem) out of the users found in the Git history. I can see this because there were Git-identities named "logonname logonn...@somedevelopershost.acme.com" when a user forgot to set its identity in the Git config. Now you've lost me... How do you "generate" users/usernames? Let's not say users/usernames are generated but "persons". One users will appear multiple (at least two) times in the Persons page (this is what I've called users before). One userperson is reflected by the Crowd user, another by the developers Git identity. My guess is that the problem is in the Crowd plugin and not in the Git plugin. I don't think this is related to the Git nor the Crowd plugin but Jenkins. Because there are multiple authentication and versioning plugins they shouldn't care about each other to solve this issue. Jenkins should provide a mechanism to associate a VCS identity with Jenkins identity (optionally provided by an authentication plugin). 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-15915) Password Parameter should not be stored (on disk)
Thomas Lehmann created JENKINS-15915 Password Parameter should not be stored (on disk) Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: parameters Created: 25/Nov/12 10:32 AM Description: The Mask Passwords Plugin helps masking the password in Jenkins' GUI. Unfortunately the passwords are already stored clear text on disk. They should not be stored. Storing them symmetrically encrypted is not necessary too, I think, as they are/should only used one time. Environment: Debian Linux Stable, Jenkins 1.462, Sun JDK 1.7 Project: Jenkins Labels: parameter security password cleartext disk unencrypted stored Priority: Critical Reporter: Thomas Lehmann 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-13631) Can't manually promote build with approval parameter
Thomas Lehmann commented on JENKINS-13631 Cant manually promote build with approval parameter As supplement to my first two comments (and to confirm Maxime's experience): I was doing parameterless promotions which lead to the discussed error. I hope this fix solved it. 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-13547) Jenkins runs extremely slow with remote crowd server
[ https://issues.jenkins-ci.org/browse/JENKINS-13547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163106#comment-163106 ] Thomas Lehmann commented on JENKINS-13547: -- I can confirm this bug in an intranet application. Since I've activated security with crowd authentication through the crowd2 plugin Jenkis is extremely slow. It takes upto 10 seconds to load the overview or a configuation page. Even opening the conextmenus takes 3-4 seconds when hovering context sensitive links. IMO this is unusable. Really! I'll try to debug this these days to tisolate the problem, but I'm sure this is related to the crowd2 plugin. Jenkins runs extremely slow with remote crowd server Key: JENKINS-13547 URL: https://issues.jenkins-ci.org/browse/JENKINS-13547 Project: Jenkins Issue Type: Bug Components: crowd2 Environment: Centos/RHEL 6.2 Jenkins 1.460 Crowd 2.2.7 Reporter: Joel Pearson Assignee: Thorsten Heit Priority: Critical When Crowd is running on a different continent to Jenkins, the performance of Jenkins is drastically affected, to the point that Jenkins is unusable. It seems like that every request to Jenkins gets authenticated to Crowd or something like that. The original Crowd plugin does not have this problem and does not affect the performance of Jenkins in any visible form. -- 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-13547) Jenkins runs extremely slow with remote crowd server
[ https://issues.jenkins-ci.org/browse/JENKINS-13547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163107#comment-163107 ] Thomas Lehmann commented on JENKINS-13547: -- Our configuration: CentOS 5.8 SunJDK 1.7.0_03-b04 on x86-64 Jenkins 1.462 Crowd 2 integration 1.4 Against Crowd 2.4.2 All other atlassian applications run quiete fast. Jenkins runs extremely slow with remote crowd server Key: JENKINS-13547 URL: https://issues.jenkins-ci.org/browse/JENKINS-13547 Project: Jenkins Issue Type: Bug Components: crowd2 Environment: Centos/RHEL 6.2 Jenkins 1.460 Crowd 2.2.7 Reporter: Joel Pearson Assignee: Thorsten Heit Priority: Critical When Crowd is running on a different continent to Jenkins, the performance of Jenkins is drastically affected, to the point that Jenkins is unusable. It seems like that every request to Jenkins gets authenticated to Crowd or something like that. The original Crowd plugin does not have this problem and does not affect the performance of Jenkins in any visible form. -- 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-13547) Jenkins runs extremely slow with remote crowd server
[
https://issues.jenkins-ci.org/browse/JENKINS-13547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163107#comment-163107
]
Thomas Lehmann edited comment on JENKINS-13547 at 5/23/12 11:56 AM:
Our configuration:
{quote}
CentOS 5.8 SunJDK 1.7.0_03-b04 on x86-64
Jenkins 1.462
Crowd 2 integration 1.4
{quote}
{quote}
Against Crowd 2.4.2
{quote}
All other atlassian applications run quiete fast.
was (Author: tholewebgods):
Our configuration:
CentOS 5.8 SunJDK 1.7.0_03-b04 on x86-64
Jenkins 1.462
Crowd 2 integration 1.4
Against Crowd 2.4.2
All other atlassian applications run quiete fast.
Jenkins runs extremely slow with remote crowd server
Key: JENKINS-13547
URL: https://issues.jenkins-ci.org/browse/JENKINS-13547
Project: Jenkins
Issue Type: Bug
Components: crowd2
Environment: Centos/RHEL 6.2
Jenkins 1.460
Crowd 2.2.7
Reporter: Joel Pearson
Assignee: Thorsten Heit
Priority: Critical
When Crowd is running on a different continent to Jenkins, the performance of
Jenkins is drastically affected, to the point that Jenkins is unusable.
It seems like that every request to Jenkins gets authenticated to Crowd or
something like that.
The original Crowd plugin does not have this problem and does not affect the
performance of Jenkins in any visible form.
--
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-13802) Downstream promotion should be prohibited/impossible when upstream promotion is outstanding
Thomas Lehmann created JENKINS-13802: Summary: Downstream promotion should be prohibited/impossible when upstream promotion is outstanding Key: JENKINS-13802 URL: https://issues.jenkins-ci.org/browse/JENKINS-13802 Project: Jenkins Issue Type: Improvement Components: promoted-builds Environment: Fedora 15 OpenJDK 1.6.0_22 on x86-64 + Jenkins 1.462 + Promoted Builds Plugin 2.5 Reporter: Thomas Lehmann The view where one can click Approve should disable the button as long as the upstream promotion is not successful done. Situation: I have three promotions configured which should only happen in this order: Deploy to Staging (refered as A) - QA OK (refered as B) - Deploy to live (refered as C) Obviously the QA should not be able to mark the build OK before it has been deployed. The Promotions are configured with these upstream criterias: - A: manual - B: manual, when A is promoted - C: manual, when B is promoted Current: B can be approved even if A has never been approved. Same for C vs. B or A. Desired: B's Approve should be disabled until A is successful approved. Same for C vs. B or A -- 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-13631) Can't manually promote build with approval parameter
[ https://issues.jenkins-ci.org/browse/JENKINS-13631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Lehmann updated JENKINS-13631: - Attachment: fix-missing-slash-in-job-name.user.js Updated Patch: fix all forms on the current page Can't manually promote build with approval parameter Key: JENKINS-13631 URL: https://issues.jenkins-ci.org/browse/JENKINS-13631 Project: Jenkins Issue Type: Bug Components: promoted-builds Affects Versions: current Environment: debian 5 Oracle JDK 1.6.0_12 Jenkins 1.461 Reporter: Aurélien Pelletier Labels: plugin Attachments: fix-missing-slash-in-job-name.user.js, fix-missing-slash-in-job-name.user.js Promoted build plugin version 2.5, it works with version 2.4 I have a job configured with a manually approved + approval parameter promotion. When I try to promoted the build using the Approve button to pass the parameters I get an error 500 with this stack trace: java.lang.IllegalArgumentException: THE_NAME_OF_THE_JENKINS_JOB at hudson.maven.ModuleName.fromString(ModuleName.java:97) at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:354) at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:117) at jenkins.model.Jenkins.getItem(Jenkins.java:2159) at jenkins.model.Jenkins.getItem(Jenkins.java:2180) at hudson.plugins.promoted_builds.conditions.ManualCondition.doApprove(ManualCondition.java:148) -- 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-13631) Can't manually promote build with approval parameter
[ https://issues.jenkins-ci.org/browse/JENKINS-13631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162785#comment-162785 ] Thomas Lehmann commented on JENKINS-13631: -- Works in Firefox 12 too: just install and activate Greasemonkey and klick the attached Script link and answer Yes on the install dialog. (Deactivate Greasemonkey to open the script wihtout installing it to what it does :) Can't manually promote build with approval parameter Key: JENKINS-13631 URL: https://issues.jenkins-ci.org/browse/JENKINS-13631 Project: Jenkins Issue Type: Bug Components: promoted-builds Affects Versions: current Environment: debian 5 Oracle JDK 1.6.0_12 Jenkins 1.461 Reporter: Aurélien Pelletier Labels: plugin Attachments: fix-missing-slash-in-job-name.user.js, fix-missing-slash-in-job-name.user.js Promoted build plugin version 2.5, it works with version 2.4 I have a job configured with a manually approved + approval parameter promotion. When I try to promoted the build using the Approve button to pass the parameters I get an error 500 with this stack trace: java.lang.IllegalArgumentException: THE_NAME_OF_THE_JENKINS_JOB at hudson.maven.ModuleName.fromString(ModuleName.java:97) at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:354) at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:117) at jenkins.model.Jenkins.getItem(Jenkins.java:2159) at jenkins.model.Jenkins.getItem(Jenkins.java:2180) at hudson.plugins.promoted_builds.conditions.ManualCondition.doApprove(ManualCondition.java:148) -- 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-13788) Git user and Crowd 2 authenticated user should be equal (one User-Id)
Thomas Lehmann created JENKINS-13788: Summary: Git user and Crowd 2 authenticated user should be equal (one User-Id) Key: JENKINS-13788 URL: https://issues.jenkins-ci.org/browse/JENKINS-13788 Project: Jenkins Issue Type: Bug Components: crowd2, git Affects Versions: current Environment: Jenkins 1.462 on CentOS 5.8 SunJDK 1.7.0_03-b04 Crowd2 Plugin 1.4 Git Plugin 1.1.12 Against Crowd 2.4.2 Reporter: Thomas Lehmann Assignee: Thorsten Heit This is very complicated to describe. I'll try to describe our setup, our Jenkins configuration's chronology the problem and my assumptions to the current bug... I'll describe the whole situation which probably makes the description harder to understand, but I want to provide as much information as possible. Please help me to make this description more specifcally and/or create another issue for separate problems. Thank you. :) Setup -- Jenkins configured to authenticate through Crowd 2 Plugin (works fine so far, also with authorization) The authenticated username is Forename Lastname (crowd-userid). Crowd holds the crentral email address of each user. Out projects are checked out through Git. Older commits may have malformed auther name and email. Recent commits are all in form Username = 'Forename Lastname' and email = 'The same email address as in crowd'. Cronology -- - This Jenkins installation started with no security configured. - I can't ensure there was never a Jenkins-based usermanagement configured as this installation was administered by a colleague before. - All jobs check out from a Git-Repository - Before today the Peoples view showed a variety of user id from more or less real names (also misleading names like root, see my assumptions below) over through odd usernames like contextMenu (we can't figure out what caused this username). - Some users seemed to appear twice (this is actually another issue) - Today I've configures authentication through the Crowd 2 Plugin - Now there are further users, one for each Crowd user that has logged in once Problem There are at least 2, sometimes 3 users (obviously depending on how much different Git users exists) in Peoples view. Only one of them, apparently the user generated out of the Git user can show information under Builds Assumptions - A username is generated for each user of a Git commit - If there was accidently no username like or login login@hostname or root root@hostname such user IDs (, login, root) will be generated So how can I... - delete these accidently created users - tell Jenkins to see/understand automatically generated user x is equal to Crowd user X or at least map each Git user to a Crow 2 user - keep Jenkins from generating user IDs for all Git users I know there are other issues and solutions on the web about removing users, but deleting in users/ did not work either. All user-directories are re-generated on Jenkins startup (all having statup date). -- 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-9093) Deploy: Allow specification of Context Path
[ https://issues.jenkins-ci.org/browse/JENKINS-9093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Lehmann reopened JENKINS-9093: - Assignee: (was: Willem Verstraeten) Deploy: Allow specification of Context Path --- Key: JENKINS-9093 URL: https://issues.jenkins-ci.org/browse/JENKINS-9093 Project: Jenkins Issue Type: Improvement Components: deploy Affects Versions: current Reporter: Daniel Jones Priority: Minor It would be great if we could specify the context-path that the .war gets deployed with. I'm trying to deploy a .war called ROOT.war, but when it's deployed via Tomcat Manager it's context path is /ROOT instead of /. After restarting Tomcat, the normal Tomcat behaviour of treating a .war called ROOT.war as the default context takes over, but then we have two contexts instead of one. -- 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-13631) Can't manually promote build with approval parameter
[
https://issues.jenkins-ci.org/browse/JENKINS-13631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162616#comment-162616
]
Thomas Lehmann edited comment on JENKINS-13631 at 5/11/12 12:27 PM:
I guess I realize what the problem is (however I am not familar with
Jenkins/Hudson nor with the promote plugin).
The passed job name is NAME-OF-THE-JOB. I've debugged the calls and tried to
reverse engineer what Jenkins.getItem() does. After that I've tried to pass
/NAME-OF-THE-JOB. It dit not fail with an exception and responded with 200
OK. After that the promotion was marked approved. So I think this did the
trick. Even though I do not know if this is correct. :)
Bad request:
$ curl -X POST --cookie JSESSIONID.*; JSESSIONID.* --form-string
'_.=NAME-OF-THE-USER' --form-string 'json={: NAME-OF-THE-USER}'
--form-string 'Submit=Approve'
'http://localhost:8070/job/NAME-OF-THE-BUILD/9/promotion/promotionProcess/Release%20Approved/promotionCondition/hudson.plugins.promoted_builds.conditions.ManualCondition/approve?job=NAME-OF-THE-BUILDbuildNumber=9promotion=Release%20Approved'
Good request:
$ curl -X POST --cookie JSESSIONID.*; JSESSIONID.* --form-string
'_.=NAME-OF-THE-USER' --form-string 'json={: NAME-OF-THE-USER}'
--form-string 'Submit=Approve'
'http://localhost:8070/job/NAME-OF-THE-BUILD/9/promotion/promotionProcess/Release%20Approved/promotionCondition/hudson.plugins.promoted_builds.conditions.ManualCondition/approve?job=/NAME-OF-THE-BUILDbuildNumber=9promotion=Release%20Approved'
As this works for me I'll write a Greasemonkey script to workaround this by
patching the formular.
Please give me feedback if the missing slash prefix is the error.
Edit: changed job name to a capitalized variable
was (Author: tholewebgods):
I guess I realize what the problem is (however I am not familar with
Jenkins/Hudson nor with the promote plugin).
The passed job name is NAME-OF-THE-JOB. I've debugged the calls and tried to
reverse engineer what Jenkins.getItem() does. After that I've tried to pass
/NAME-OF-THE-JOB. It dit not fail with an exception and responded with 200
OK. After that the promotion was marked approved. So I think this did the
trick. Even though I do not know if this is correct. :)
Bad request:
$ curl -X POST --cookie JSESSIONID.*; JSESSIONID.* --form-string
'_.=NAME-OF-THE-USER' --form-string 'json={: NAME-OF-THE-USER}'
--form-string 'Submit=Approve'
'http://localhost:8070/job/Build-1/9/promotion/promotionProcess/Release%20Approved/promotionCondition/hudson.plugins.promoted_builds.conditions.ManualCondition/approve?job=Build-1buildNumber=9promotion=Release%20Approved'
Good request:
$ curl -X POST --cookie JSESSIONID.*; JSESSIONID.* --form-string
'_.=NAME-OF-THE-USER' --form-string 'json={: NAME-OF-THE-USER}'
--form-string 'Submit=Approve'
'http://localhost:8070/job/Build-1/9/promotion/promotionProcess/Release%20Approved/promotionCondition/hudson.plugins.promoted_builds.conditions.ManualCondition/approve?job=/Build-1buildNumber=9promotion=Release%20Approved'
As this works for me I'll write a Greasemonkey script to workaround this by
patching the formular.
Please give me feedback if the missing slash prefix is the error.
Can't manually promote build with approval parameter
Key: JENKINS-13631
URL: https://issues.jenkins-ci.org/browse/JENKINS-13631
Project: Jenkins
Issue Type: Bug
Components: promoted-builds
Affects Versions: current
Environment: debian 5
Oracle JDK 1.6.0_12
Jenkins 1.461
Reporter: Aurélien Pelletier
Labels: plugin
Attachments: fix-missing-slash-in-job-name.user.js
Promoted build plugin version 2.5, it works with version 2.4
I have a job configured with a manually approved + approval parameter
promotion.
When I try to promoted the build using the Approve button to pass the
parameters I get an error 500 with this stack trace:
java.lang.IllegalArgumentException: THE_NAME_OF_THE_JENKINS_JOB
at hudson.maven.ModuleName.fromString(ModuleName.java:97)
at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:354)
at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:117)
at jenkins.model.Jenkins.getItem(Jenkins.java:2159)
at jenkins.model.Jenkins.getItem(Jenkins.java:2180)
at
hudson.plugins.promoted_builds.conditions.ManualCondition.doApprove(ManualCondition.java:148)
--
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-13751) Promoted Builds plugin should pass actual/root job to Git plublisher
Thomas Lehmann created JENKINS-13751:
Summary: Promoted Builds plugin should pass actual/root job to
Git plublisher
Key: JENKINS-13751
URL: https://issues.jenkins-ci.org/browse/JENKINS-13751
Project: Jenkins
Issue Type: Bug
Components: promoted-builds
Affects Versions: current
Environment: CentOS 5.8 SunJDK 1.7.0_03-b04 and Fedora 15 OpenJDK
1.6.0_22 both on x86-64.
Both Jenkins 1.462.
Both Git Plugin 1.1.18
Both Promoted Builds Plugin 2.5
Reporter: Thomas Lehmann
The Promoted Builds plugin should pass the actual job instance to the Git
Publisher {{perform()}} when performing post-promote action.
I wondered why publishing Git tags did not work as post promote action and
debugged the code a bit.
The promotion will fail with
{quote}
Promoting JOBNAME #13
failed build hudson.plugins.git.GitPublisher@7cdd86df SUCCESS
Finished: FAILURE
{quote}
In the class {{GitPublisher}} I see {{build.getProject()}} returns a project
instance pointing to the build and promote. the {{getScm()}} then will of
course return a NullSCM. I think {{getProject()}} should return the base/actual
job so that the Git publisher wil refer to the correct project.
A Git Publisher setup as post build action works quiet fine.
--
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-13631) Can't manually promote build with approval parameter
[ https://issues.jenkins-ci.org/browse/JENKINS-13631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162613#comment-162613 ] Thomas Lehmann commented on JENKINS-13631: -- I can reproduce this bug with Jenkins 1.462, Promoted Builds 2.5 and OpenJDK Runtime Environment (IcedTea6 1.10.6) (fedora-63.1.10.6.fc15-x86_64) Can't manually promote build with approval parameter Key: JENKINS-13631 URL: https://issues.jenkins-ci.org/browse/JENKINS-13631 Project: Jenkins Issue Type: Bug Components: promoted-builds Affects Versions: current Environment: debian 5 Oracle JDK 1.6.0_12 Jenkins 1.461 Reporter: Aurélien Pelletier Labels: plugin Promoted build plugin version 2.5, it works with version 2.4 I have a job configured with a manually approved + approval parameter promotion. When I try to promoted the build using the Approve button to pass the parameters I get an error 500 with this stack trace: java.lang.IllegalArgumentException: THE_NAME_OF_THE_JENKINS_JOB at hudson.maven.ModuleName.fromString(ModuleName.java:97) at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:354) at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:117) at jenkins.model.Jenkins.getItem(Jenkins.java:2159) at jenkins.model.Jenkins.getItem(Jenkins.java:2180) at hudson.plugins.promoted_builds.conditions.ManualCondition.doApprove(ManualCondition.java:148) -- 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-13631) Can't manually promote build with approval parameter
[
https://issues.jenkins-ci.org/browse/JENKINS-13631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162616#comment-162616
]
Thomas Lehmann commented on JENKINS-13631:
--
I guess I realize what the problem is (however I am not familar with
Jenkins/Hudson nor with the promote plugin).
The passed job name is NAME-OF-THE-JOB. I've debugged the calls and tried to
reverse engineer what Jenkins.getItem() does. After that I've tried to pass
/NAME-OF-THE-JOB. It dit not fail with an exception and responded with 200
OK. After that the promotion was marked approved. So I think this did the
trick. Even though I do not know if this is correct. :)
Bad request:
$ curl -X POST --cookie JSESSIONID.*; JSESSIONID.* --form-string
'_.=NAME-OF-THE-USER' --form-string 'json={: NAME-OF-THE-USER}'
--form-string 'Submit=Approve'
'http://localhost:8070/job/Build-1/9/promotion/promotionProcess/Release%20Approved/promotionCondition/hudson.plugins.promoted_builds.conditions.ManualCondition/approve?job=Build-1buildNumber=9promotion=Release%20Approved'
Good request:
$ curl -X POST --cookie JSESSIONID.*; JSESSIONID.* --form-string
'_.=NAME-OF-THE-USER' --form-string 'json={: NAME-OF-THE-USER}'
--form-string 'Submit=Approve'
'http://localhost:8070/job/Build-1/9/promotion/promotionProcess/Release%20Approved/promotionCondition/hudson.plugins.promoted_builds.conditions.ManualCondition/approve?job=/Build-1buildNumber=9promotion=Release%20Approved'
As this works for me I'll write a Greasemonkey script to workaround this by
patching the formular.
Please give me feedback if the missing slash prefix is the error.
Can't manually promote build with approval parameter
Key: JENKINS-13631
URL: https://issues.jenkins-ci.org/browse/JENKINS-13631
Project: Jenkins
Issue Type: Bug
Components: promoted-builds
Affects Versions: current
Environment: debian 5
Oracle JDK 1.6.0_12
Jenkins 1.461
Reporter: Aurélien Pelletier
Labels: plugin
Promoted build plugin version 2.5, it works with version 2.4
I have a job configured with a manually approved + approval parameter
promotion.
When I try to promoted the build using the Approve button to pass the
parameters I get an error 500 with this stack trace:
java.lang.IllegalArgumentException: THE_NAME_OF_THE_JENKINS_JOB
at hudson.maven.ModuleName.fromString(ModuleName.java:97)
at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:354)
at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:117)
at jenkins.model.Jenkins.getItem(Jenkins.java:2159)
at jenkins.model.Jenkins.getItem(Jenkins.java:2180)
at
hudson.plugins.promoted_builds.conditions.ManualCondition.doApprove(ManualCondition.java:148)
--
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-13631) Can't manually promote build with approval parameter
[ https://issues.jenkins-ci.org/browse/JENKINS-13631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Lehmann updated JENKINS-13631: - Attachment: fix-missing-slash-in-job-name.user.js Successfully tested with recent Chrome. Not tested with Firefox/Greasemonkey or Safari. Install by opening this file in your browser (browse to file:///path/to/fix-missing-slash-in-job-name.user.js). Can't manually promote build with approval parameter Key: JENKINS-13631 URL: https://issues.jenkins-ci.org/browse/JENKINS-13631 Project: Jenkins Issue Type: Bug Components: promoted-builds Affects Versions: current Environment: debian 5 Oracle JDK 1.6.0_12 Jenkins 1.461 Reporter: Aurélien Pelletier Labels: plugin Attachments: fix-missing-slash-in-job-name.user.js Promoted build plugin version 2.5, it works with version 2.4 I have a job configured with a manually approved + approval parameter promotion. When I try to promoted the build using the Approve button to pass the parameters I get an error 500 with this stack trace: java.lang.IllegalArgumentException: THE_NAME_OF_THE_JENKINS_JOB at hudson.maven.ModuleName.fromString(ModuleName.java:97) at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:354) at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:117) at jenkins.model.Jenkins.getItem(Jenkins.java:2159) at jenkins.model.Jenkins.getItem(Jenkins.java:2180) at hudson.plugins.promoted_builds.conditions.ManualCondition.doApprove(ManualCondition.java:148) -- 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-13631) Can't manually promote build with approval parameter
[ https://issues.jenkins-ci.org/browse/JENKINS-13631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162619#comment-162619 ] Thomas Lehmann edited comment on JENKINS-13631 at 5/9/12 6:16 PM: -- Attached user script. Successfully tested with recent Chrome. Not tested with Firefox/Greasemonkey or Safari. Install by opening this file in your browser (browse to file:///path/to/fix-missing-slash-in-job-name.user.js). Adapt the match URL. was (Author: tholewebgods): Attached user script. Successfully tested with recent Chrome. Not tested with Firefox/Greasemonkey or Safari. Install by opening this file in your browser (browse to file:///path/to/fix-missing-slash-in-job-name.user.js). Can't manually promote build with approval parameter Key: JENKINS-13631 URL: https://issues.jenkins-ci.org/browse/JENKINS-13631 Project: Jenkins Issue Type: Bug Components: promoted-builds Affects Versions: current Environment: debian 5 Oracle JDK 1.6.0_12 Jenkins 1.461 Reporter: Aurélien Pelletier Labels: plugin Attachments: fix-missing-slash-in-job-name.user.js Promoted build plugin version 2.5, it works with version 2.4 I have a job configured with a manually approved + approval parameter promotion. When I try to promoted the build using the Approve button to pass the parameters I get an error 500 with this stack trace: java.lang.IllegalArgumentException: THE_NAME_OF_THE_JENKINS_JOB at hudson.maven.ModuleName.fromString(ModuleName.java:97) at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:354) at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:117) at jenkins.model.Jenkins.getItem(Jenkins.java:2159) at jenkins.model.Jenkins.getItem(Jenkins.java:2180) at hudson.plugins.promoted_builds.conditions.ManualCondition.doApprove(ManualCondition.java:148) -- 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-13631) Can't manually promote build with approval parameter
[ https://issues.jenkins-ci.org/browse/JENKINS-13631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162619#comment-162619 ] Thomas Lehmann edited comment on JENKINS-13631 at 5/9/12 6:16 PM: -- Attached user script. Successfully tested with recent Chrome. Not tested with Firefox/Greasemonkey or Safari. Install by opening this file in your browser (browse to file:///path/to/fix-missing-slash-in-job-name.user.js). was (Author: tholewebgods): Successfully tested with recent Chrome. Not tested with Firefox/Greasemonkey or Safari. Install by opening this file in your browser (browse to file:///path/to/fix-missing-slash-in-job-name.user.js). Can't manually promote build with approval parameter Key: JENKINS-13631 URL: https://issues.jenkins-ci.org/browse/JENKINS-13631 Project: Jenkins Issue Type: Bug Components: promoted-builds Affects Versions: current Environment: debian 5 Oracle JDK 1.6.0_12 Jenkins 1.461 Reporter: Aurélien Pelletier Labels: plugin Attachments: fix-missing-slash-in-job-name.user.js Promoted build plugin version 2.5, it works with version 2.4 I have a job configured with a manually approved + approval parameter promotion. When I try to promoted the build using the Approve button to pass the parameters I get an error 500 with this stack trace: java.lang.IllegalArgumentException: THE_NAME_OF_THE_JENKINS_JOB at hudson.maven.ModuleName.fromString(ModuleName.java:97) at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:354) at hudson.maven.MavenModuleSet.getItem(MavenModuleSet.java:117) at jenkins.model.Jenkins.getItem(Jenkins.java:2159) at jenkins.model.Jenkins.getItem(Jenkins.java:2180) at hudson.plugins.promoted_builds.conditions.ManualCondition.doApprove(ManualCondition.java:148) -- 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-9093) Deploy: Allow specification of Context Path
[ https://issues.jenkins-ci.org/browse/JENKINS-9093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162492#comment-162492 ] Thomas Lehmann commented on JENKINS-9093: - I just built a snapshot of this plugin (at 37ae083) an tried the context path feature. It unfortunately does not work. Trying to deploy to a GlassFish 3.1.2 with ContextRoot /A deployed the application with ContextRoot / (examined with GlassFish admin website). Deploy: Allow specification of Context Path --- Key: JENKINS-9093 URL: https://issues.jenkins-ci.org/browse/JENKINS-9093 Project: Jenkins Issue Type: Improvement Components: deploy Affects Versions: current Reporter: Daniel Jones Assignee: Willem Verstraeten Priority: Minor It would be great if we could specify the context-path that the .war gets deployed with. I'm trying to deploy a .war called ROOT.war, but when it's deployed via Tomcat Manager it's context path is /ROOT instead of /. After restarting Tomcat, the normal Tomcat behaviour of treating a .war called ROOT.war as the default context takes over, but then we have two contexts instead of one. -- 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
