Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-8969

Parameterized project name does not work with Jenkins 1.399

    Details

    • Similar Issues:

      Description

      The copy artifact plugin does not seem to work if the project name is specified in a build parameter. For example, I receive the following error in then Jenkins build console:

      Started by upstream project "MyProject Nightly" build number 209
      ...........
      Unable to find project for artifact copy: MyProject Nightly/com.project.install$ProjectDistribution/

      Here I am trying to copy the artifacts from the MyProject Nightly job. Within the Copy Artifact configuration, I have the word "Nightly" in a build parameter like so:

      MyProject $SOURCE_PROJECT/com.project.install$ProjectDistribution/

      From the above log, you can see that the substitution is being made correctly, as the error message says the same build name as the triggering project. However this build fails because it says it cannot find the project. If I remove the parameter and configure the plugin like so:

      MyProject Nightly/com.project.install$ProjectDistribution/

      it works fine. The error only occurs when using a build parameter.

        Attachments

          Activity

          Hide
          gms5002 Greg Snyder added a comment -

          I have also tested this where the entire job name is put into the parameter, rather than part of it as described above. The same behavior occurs: it does not work from the parameter, but if I copy and paste the parameter value into the plugin configuration it works fine.

          Show
          gms5002 Greg Snyder added a comment - I have also tested this where the entire job name is put into the parameter, rather than part of it as described above. The same behavior occurs: it does not work from the parameter, but if I copy and paste the parameter value into the plugin configuration it works fine.
          Hide
          mindless Alan Harder added a comment -

          I haven't yet tested in jenkins itself, but I tried running the unit tests against 1.399 and they passed.
          Has this worked for you in prior jenkins/hudson versions? Which ones? What version(s) of copyartifact?
          Is $ProjectDistribution a "string" type build parameter?

          Show
          mindless Alan Harder added a comment - I haven't yet tested in jenkins itself, but I tried running the unit tests against 1.399 and they passed. Has this worked for you in prior jenkins/hudson versions? Which ones? What version(s) of copyartifact? Is $ProjectDistribution a "string" type build parameter?
          Hide
          mindless Alan Harder added a comment -

          Confirmed it doesn't work in jenkins itself.. odd that the error message does show the properly-expanded parameter. Investigating..

          Show
          mindless Alan Harder added a comment - Confirmed it doesn't work in jenkins itself.. odd that the error message does show the properly-expanded parameter. Investigating..
          Hide
          mindless Alan Harder added a comment -

          Oh yeah.. I think this is not a bug, but a security protection. This is what it says in the help for project name:

          May contain references to build parameters like $PARAM (note that when a parameter is used, the source project must be accessible to all authenticated users; this prevents use of parameters to access artifacts of private jobs).

          Can you confirm that the project you're trying to reference is not accessible to all logged in users? If you don't want it accessible to guest users, try adding project-permissions and give Job/Read permission to "authenticated" (builtin group).

          Let me know if this solves the problem.. I should update the error message in the console to mention that permissions may be the cause of failure.

          Show
          mindless Alan Harder added a comment - Oh yeah.. I think this is not a bug, but a security protection. This is what it says in the help for project name: May contain references to build parameters like $PARAM (note that when a parameter is used, the source project must be accessible to all authenticated users; this prevents use of parameters to access artifacts of private jobs). Can you confirm that the project you're trying to reference is not accessible to all logged in users? If you don't want it accessible to guest users, try adding project-permissions and give Job/Read permission to "authenticated" (builtin group). Let me know if this solves the problem.. I should update the error message in the console to mention that permissions may be the cause of failure.
          Hide
          gms5002 Greg Snyder added a comment -

          Hmmm, interesting. I changed the setting Access Control -> Authorization to "Anyone can do anything" and it works fine. Previously, it was set to "Collabnet Authorization" (I have Jenkins integrated with Collabnet TeamForge).

          So my question would be, is there any way to make this work with Collabnet Authorization? The way it is set up, everyone can see and build all of the jobs - I just want to keep people from being able to access the configuration pages.

          Show
          gms5002 Greg Snyder added a comment - Hmmm, interesting. I changed the setting Access Control -> Authorization to "Anyone can do anything" and it works fine. Previously, it was set to "Collabnet Authorization" (I have Jenkins integrated with Collabnet TeamForge). So my question would be, is there any way to make this work with Collabnet Authorization? The way it is set up, everyone can see and build all of the jobs - I just want to keep people from being able to access the configuration pages.
          Hide
          mindless Alan Harder added a comment -

          Hmm.. I tried this with per-project matrix authorization, and it works to grant permission to "authenticated". I wonder if this is a bug in collabnet to not support the SecurityRealm.AUTHENTICATED_AUTHORITY token.

          Show
          mindless Alan Harder added a comment - Hmm.. I tried this with per-project matrix authorization, and it works to grant permission to "authenticated". I wonder if this is a bug in collabnet to not support the SecurityRealm.AUTHENTICATED_AUTHORITY token.
          Hide
          mindless Alan Harder added a comment -

          Hm, from this collabnet class I'd think this would work ok.. the Authentication object that copyartifact passes should return true for isAuthenticated.

          Show
          mindless Alan Harder added a comment - Hm, from this collabnet class I'd think this would work ok.. the Authentication object that copyartifact passes should return true for isAuthenticated.
          Hide
          mindless Alan Harder added a comment -

          https://github.com/jenkinsci/collabnet-plugin/blob/master/src/main/java/hudson/plugins/collabnet/auth/CNRootACL.java
          Ok, there are 2 if conditions here that do "return false" without delegating to "inner", which is the class I referenced above that would return true. I'm not passing a CNAuthentication, so looks like it bails out there..

          Show
          mindless Alan Harder added a comment - https://github.com/jenkinsci/collabnet-plugin/blob/master/src/main/java/hudson/plugins/collabnet/auth/CNRootACL.java Ok, there are 2 if conditions here that do "return false" without delegating to "inner", which is the class I referenced above that would return true. I'm not passing a CNAuthentication, so looks like it bails out there..
          Hide
          gms5002 Greg Snyder added a comment -

          Thanks for the help Alan! I can remote debug on our Jenkins instance if you need....

          Show
          gms5002 Greg Snyder added a comment - Thanks for the help Alan! I can remote debug on our Jenkins instance if you need....
          Hide
          mindless Alan Harder added a comment -

          Let's make a deal.. collabnet has lots of changes since its last release. If I prepare a fix for this issue, will you test out a dev build and let me know if it looks ok to release?

          Show
          mindless Alan Harder added a comment - Let's make a deal.. collabnet has lots of changes since its last release. If I prepare a fix for this issue, will you test out a dev build and let me know if it looks ok to release?
          Hide
          gms5002 Greg Snyder added a comment -

          Sorry did not see your last comment, I agree it seems to bail out at line 63. So is this something that should be changed in the Collabnet plugin or should the Copy Artifact plugin send a CNAuthentication? Please forgive my lack of familiarity with Jenkins authentication.

          Show
          gms5002 Greg Snyder added a comment - Sorry did not see your last comment, I agree it seems to bail out at line 63. So is this something that should be changed in the Collabnet plugin or should the Copy Artifact plugin send a CNAuthentication? Please forgive my lack of familiarity with Jenkins authentication.
          Hide
          gms5002 Greg Snyder added a comment -

          Sure thing! I use Jenkins all the time, so happy to help out where I can.

          Show
          gms5002 Greg Snyder added a comment - Sure thing! I use Jenkins all the time, so happy to help out where I can.
          Hide
          mindless Alan Harder added a comment -

          OK, let's start with a build of what's currently in svn with a few "jenkins-ification" changes:
          http://ci.jenkins-ci.org/view/Plugins/job/plugins_collabnet/2/org.jenkins-ci.plugins$collabnet/
          While I work on a fix for this issue, please give that build a try to make sure the existing changes work OK.

          Show
          mindless Alan Harder added a comment - OK, let's start with a build of what's currently in svn with a few "jenkins-ification" changes: http://ci.jenkins-ci.org/view/Plugins/job/plugins_collabnet/2/org.jenkins-ci.plugins$collabnet/ While I work on a fix for this issue, please give that build a try to make sure the existing changes work OK.
          Hide
          gms5002 Greg Snyder added a comment -

          Alright, so far so good. I tested the login based on Team Forge credentials and controlling user permissions from within Team Forge.

          The only thing I noticed with the build is that the "The authorization settings would lock the current user out of this page. You may want to add your username to the user list." warning will not go away after I enter my username in the admin users list. I have logged out and back in and the warning is still present. This is in Manage Jenkins -> Configure System -> Access Control -> Authorization. It shows up between the "Jenkins Admin Groups" and "Jenkins Read-Only Users" rows.

          Show
          gms5002 Greg Snyder added a comment - Alright, so far so good. I tested the login based on Team Forge credentials and controlling user permissions from within Team Forge. The only thing I noticed with the build is that the "The authorization settings would lock the current user out of this page. You may want to add your username to the user list." warning will not go away after I enter my username in the admin users list. I have logged out and back in and the warning is still present. This is in Manage Jenkins -> Configure System -> Access Control -> Authorization. It shows up between the "Jenkins Admin Groups" and "Jenkins Read-Only Users" rows.
          Show
          mindless Alan Harder added a comment - Ok, give this a go with copyartifact: http://ci.jenkins-ci.org/view/Plugins/job/plugins_collabnet/3/org.jenkins-ci.plugins$collabnet/
          Hide
          gms5002 Greg Snyder added a comment -

          Thanks! Works like a charm for a build I triggered manually. I have some nightly builds which will run later tonight - those will be triggered by a timer. Is there any other type of trigger you want me to test?

          I tested this in Jenkins 1.400 as well and it works fine.

          Show
          gms5002 Greg Snyder added a comment - Thanks! Works like a charm for a build I triggered manually. I have some nightly builds which will run later tonight - those will be triggered by a timer. Is there any other type of trigger you want me to test? I tested this in Jenkins 1.400 as well and it works fine.
          Hide
          mindless Alan Harder added a comment -

          I don't know exactly how collabnet works, but from the code it looks like you can go into a particular job and enable some job-specific permissions? Can you try this, and try copying artifacts from such a job, using a parameter to select that job? I'm expecting it won't work (adding the job-specific params takes away the "accessible to all authenticated users"), but want to make sure it doesn't totally break or something..

          Show
          mindless Alan Harder added a comment - I don't know exactly how collabnet works, but from the code it looks like you can go into a particular job and enable some job-specific permissions? Can you try this, and try copying artifacts from such a job, using a parameter to select that job? I'm expecting it won't work (adding the job-specific params takes away the "accessible to all authenticated users"), but want to make sure it doesn't totally break or something..
          Hide
          gms5002 Greg Snyder added a comment -

          I believe I already have this enabled, and it DOES work. Basically, in Team Forge users can be a member of one or more projects and project administrators can assign you permissions for SVN, Jenkins, etc. In the option you are talking about above, Jenkins wants to know the Team Forge project the job is associated with so that it can find the right permissions. What I could try tomorrow when I get back to the office is put the "copy from" job in one Team Forge project and the downstream job in a different project. Then, I can revoke my coworker's access to the "copy from" job and see what happens when they build the downstream job (this should presumably not work). Does that make sense, or am I off base?

          Show
          gms5002 Greg Snyder added a comment - I believe I already have this enabled, and it DOES work. Basically, in Team Forge users can be a member of one or more projects and project administrators can assign you permissions for SVN, Jenkins, etc. In the option you are talking about above, Jenkins wants to know the Team Forge project the job is associated with so that it can find the right permissions. What I could try tomorrow when I get back to the office is put the "copy from" job in one Team Forge project and the downstream job in a different project. Then, I can revoke my coworker's access to the "copy from" job and see what happens when they build the downstream job (this should presumably not work). Does that make sense, or am I off base?
          Hide
          mindless Alan Harder added a comment -

          ok, marking as resolved in collabnet 1.1.6

          Show
          mindless Alan Harder added a comment - ok, marking as resolved in collabnet 1.1.6

            People

            • Assignee:
              mindless Alan Harder
              Reporter:
              gms5002 Greg Snyder
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: