[JIRA] Created: (JENKINS-10313) Fails to copy artifacts from one multi-configuration build to another

[snrkiwi71@java.net (JIRA)]

Fails to copy artifacts from one multi-configuration build to another
---------------------------------------------------------------------

Key: JENKINS-10313
URL: https://issues.jenkins-ci.org/browse/JENKINS-10313
Project: Jenkins
Issue Type: Bug
Components: copyartifact
Affects Versions: current
Environment: Mac OS X 10.6.8 client running Jenkins Master
Ubuntu 10.04 running Jenkins slave
Copy Artifact Plugin v1.16
Jenkins v1.420
Reporter: snrkiwi71
Assignee: Alan Harder

[can't find anything on this in the issues tracker, nor the 'net]

Project A ("ztest1") is a multi-configuration job that produces artifacts for Ubuntu and Mac OS X (axes values = macosx64, ubuntuLynx32), for two fake branches (axes values = x, y). Project B ("ztest2") wants access to the appropriate artifacts from A, given the OS/branch combination.

Using "ztest1/label=macosx64,branch=x" as the "Project name" for copy artifacts works, for all B combinations, but this obviously copies the artifacts for macosx64/x into all B combinations.

Using "ztest1/label=$label,branch=x" instead produces the following error.
{{Unable to find project for artifact copy: ztest1/label=macosx64,branch=x
This may be due to incorrect project name or permission settings; see help for project name in job configuration.
Build step 'Copy artifacts from another project' marked build as failure}}

The actual project name, including the parameters, is correct, but it fails. The same happens if you use "...,branch=$branch" also.

The copy artifacts help instructs
{{To copy artifacts from one matrix project to another, use a parameter to select the matching configuration in the source project. Example: OtherMatrixJob/jdk=$jdk}}
so I believe that the above syntax is correct.

The Hudson log for failed B build shows only
{{Jul 12, 2011 12:16:43 PM hudson.model.Run run
INFO: ztest2 #12 main build action completed: FAILURE
Jul 12, 2011 12:16:42 PM hudson.model.Run run
INFO: ztest2 » x,macosx64 #12 main build action completed: FAILURE
Jul 12, 2011 12:16:33 PM hudson.model.Run run
INFO: ztest2 #11 main build action completed: FAILURE
Jul 12, 2011 12:16:32 PM hudson.model.Run run
INFO: ztest2 » x,macosx64 #11 main build action completed: FAILURE
Jul 12, 2011 12:13:06 PM hudson.model.Run run
INFO: ztest2 #10 main build action completed: FAILURE}}

--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[mindless@java.net (JIRA)]

[ https://issues.jenkins-ci.org/browse/JENKINS-10313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=150828#comment-150828 ]

Alan Harder commented on JENKINS-10313:
---------------------------------------

What authorization model does your jenkins use, and what are the permissions for ztest1? Please read the info about permissions + use of params at the top of the project-name help and check if that is the problem here. As soon as you introduce any $param in the project-name setting it makes this permissions check.

[snrkiwi71@java.net (JIRA)]

[ https://issues.jenkins-ci.org/browse/JENKINS-10313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=152159#comment-152159 ]

snrkiwi71 commented on JENKINS-10313:
-------------------------------------

Using Matrix-based security. Only way to get it to work is for the Anonymous user to have Job.Read permissions. Maybe add this specific note to the help text you indicated? I'd looked there, but it wasn't specific enough on what permissions work. I had to figure it out through trial-and-error.

Also, "Logged-in users can do anything" gets it to work also, but that approach doesn't work for us.

Thanks, issue closed.

[mindless@java.net (JIRA)]

[ https://issues.jenkins-ci.org/browse/JENKINS-10313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alan Harder resolved JENKINS-10313.
-----------------------------------

Resolution: Not A Defect

[tyra3l@gmail.com (JIRA)]

[ https://issues.jenkins-ci.org/browse/JENKINS-10313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=153964#comment-153964 ]

Ferenc Kovacs commented on JENKINS-10313:
-----------------------------------------

the Role strategy plugin also borked: adding only a project based job read isn't enough. :/

[brian@whamcloud.com (JIRA)]

[ https://issues.jenkins-ci.org/browse/JENKINS-10313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Murrell reopened JENKINS-10313:
-------------------------------------


How can this be Resolved/Not A Defect? I'm going to Reopen for further discussion.

Requiring any project that will be the source of a Copy Artifacts action to have to be readable even by all authenticated users eliminates any use one can get out of individual or group ACLs and reduces the effective security model to only two groups of people, authenticated and non-authenticated.

i.e. I cannot create a project that is readable by only some authenticated users.

The solution, it seems to me (a layperson in terms of any knowledge of the architecture of Jenkins) is that this plugin should be represented by a particular authenticated user that one can assign read permission to in one's ACLs.

If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa

[brian@whamcloud.com (JIRA)]

[ https://issues.jenkins-ci.org/browse/JENKINS-10313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=162844#comment-162844 ]

Brian Murrell edited comment on JENKINS-10313 at 5/16/12 7:36 PM:
------------------------------------------------------------------

How can this be Resolved/Not A Defect? I'm going to Reopen for further discussion.

Requiring any project that will be the source of a Copy Artifacts action to have to be readable even by all authenticated users eliminates any use one can get out of individual or group ACLs and reduces the effective security model to only two groups of people, authenticated and non-authenticated.

i.e. I cannot create a project that is readable by only some authenticated users.

The solution, it seems to me (a layperson in terms of any knowledge of the architecture of Jenkins) is that this plugin should be run with the permissions of the user initiating the job that the plugin is being used in thus one can assign read permission to people expected to be able to read the artifacts in one's ACLs.

was (Author: brian):

How can this be Resolved/Not A Defect? I'm going to Reopen for further discussion.

Requiring any project that will be the source of a Copy Artifacts action to have to be readable even by all authenticated users eliminates any use one can get out of individual or group ACLs and reduces the effective security model to only two groups of people, authenticated and non-authenticated.

i.e. I cannot create a project that is readable by only some authenticated users.

The solution, it seems to me (a layperson in terms of any knowledge of the architecture of Jenkins) is that this plugin should be represented by a particular authenticated user that one can assign read permission to in one's ACLs.

If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa

[mindless@java.net (JIRA)]

Alan Harder updated JENKINS-10313

Fails to copy artifacts from one multi-configuration build to another

When the source project is using a variable, it is not known at the time the configuration is saved (when you use a particular project, we can check if that project is accessible to the person saving the configuration). Thus, we have to do some permission check when the job is run. I chose a simple solution that requires fairly open permissions, but at least makes the permissions clear. A pseudo-user as you suggest could work, but care would need to be taken to ensure the security implications of granting permissions to this user are made clear. Another solution that would work just for the multi-configuration case would be to detect when the variable is only used for selecting a particular configuration, but the project itself is fixed.. thus a permission check against that project could be done when the configuration is saved. Change By: Alan Harder (11/Jul/12 2:31 AM) Issue Type: Bug New Feature Assignee: Alan Harder

This message is automatically generated by JIRA.

If you think it was sent incorrectly, please contact your JIRA administrators.

[peter.wolf@sri.com (JIRA)]

Peter Wolf commented on JENKINS-10313

Fails to copy artifacts from one multi-configuration build to another

Hi we just ran into this problem. We are using role base authentication and have a $parm in the "Copy artifacts from another project"->"Project name" field and when that was set it would fail to copy artifacts. However if we hard code in the name of the project to copy from it would work just fine

This message is automatically generated by JIRA.

If you think it was sent incorrectly, please contact your JIRA administrators.

[peleg@hp.com (JIRA)]

Sega assigned JENKINS-10313 to Sega

Fails to copy artifacts from one multi-configuration build to another

Change By: Sega (31/May/13 4:05 AM) Assignee: Sega

This message is automatically generated by JIRA.

If you think it was sent incorrectly, please contact your JIRA administrators.

[peleg@hp.com (JIRA)]

Sega assigned JENKINS-10313 to Unassigned

Fails to copy artifacts from one multi-configuration build to another

Change By: Sega (31/May/13 4:07 AM) Assignee: Sega

This message is automatically generated by JIRA.

If you think it was sent incorrectly, please contact your JIRA administrators.

[peleg@hp.com (JIRA)]

Sega assigned JENKINS-10313 to Sega

Fails to copy artifacts from one multi-configuration build to another

Change By: Sega (31/May/13 4:07 AM) Assignee: Sega

This message is automatically generated by JIRA.

If you think it was sent incorrectly, please contact your JIRA administrators.

[peleg@hp.com (JIRA)]

Sega assigned JENKINS-10313 to snrkiwi71

Fails to copy artifacts from one multi-configuration build to another

Change By: Sega (31/May/13 4:07 AM)

Assignee: Sega snrkiwi71

This message is automatically generated by JIRA.

If you think it was sent incorrectly, please contact your JIRA administrators.

[uldis.karlovskis@gmail.com (JIRA)]

Uldis Karlovs-Karlovskis commented on JENKINS-10313

Fails to copy artifacts from one multi-configuration build to another

Oh, this is quite disappointing. I need to have secured jobs for different projects so I can't allow authenticated users to see everything. Now instead of one generic job I must create all builds of possible choices...

This message is automatically generated by JIRA.

If you think it was sent incorrectly, please contact your JIRA administrators.

[mattismyname@gmail.com (JIRA)]

Matt Gumbel commented on JENKINS-10313

Fails to copy artifacts from one multi-configuration build to another

To work around this in our environment, I just built my own version of the plugin with the check in question commented out. Total hack, but worth it to avoid the alternative...

This message is automatically generated by JIRA.

If you think it was sent incorrectly, please contact your JIRA administrators.

[devld@ikedam.jp (JIRA)]

ikedam resolved JENKINS-10313 as Fixed

Fails to copy artifacts from one multi-configuration build to another

This looks permission issue. copyartifact now provides some options to control permissions. Please see https://wiki.jenkins-ci.org/display/JENKINS/Copy+Artifact+Plugin#CopyArtifactPlugin-Permissionstocopyartifact for details. Change By: ikedam (07/Apr/14 3:15 PM) Status: Reopened Resolved Resolution: Fixed

This message is automatically generated by JIRA.

If you think it was sent incorrectly, please contact your JIRA administrators.