-
Bug
-
Resolution: Fixed
-
Major
-
None
-
Linux
-
Powered by SuggestiMate
The clone workspace plugin doesn't seem to preserve the permissions of the files in the cloned workspace.
How to reproduce:
- set up a job that stores the workspace
- create a shell script with "execution" permission in the workspace
- run the job
- create a job that clones the workspace
- run the job
- examine the permissions of the script: the execution permission is gone
[JENKINS-9577] Clone workspace does not preserve permissions
Alternative fix by using Ant's zip implementation in Filepath.unzip:
Code changed in jenkins
User: Ciprian Ciubotariu
Path:
changelog.html
core/src/main/java/hudson/FilePath.java
http://jenkins-ci.org/commit/jenkins/37a22a1cacc756fc9f1e6e6c3a0a7fa882e19944
Log:
[FIXED JENKINS-9577] Apply file permissions from zip archives
Using the zip support classes just like Ant does in order to apply
permissions. As a side-effect, remote streams need to be stored in a
temporary file before actually unzipping them.
I'm sorry to say that this does not seem to have fixed the bug.
I'm running 1.431 on a Linux machine, and just to test the bug, I have created two test jobs, one that creates a file with execute permissions and packs it into a workspace, and one which simply unpacks the workspace and runs 'ls -l':
http://espressomd.org/jenkins/view/All/job/Test-pack/
http://espressomd.org/jenkins/view/All/job/Test-unpack/
After unpacking, the execute permission of "test.sh" is gone.
I can confirm this is not fixed. I installed 1.431 and ran the same test that Olaf did, and I also see that the file does not have executable permissions after the copy.
I like to add: the problem seems to be unpacking the workspace, because if I manually unpack the file workspace.zip in the jobs subdir, the permissions are correctly retained.
I have retested the code with my snapshot build. Here is the output of ls -l on the child job (ignore the "hudson" user - I've had hudson before jenkins came out):
Started by upstream project "test-zip-step1" build number 18
Building remotely on pink
[test-zip-step2] $ /bin/sh -xe /tmp/hudson3057288463521800811.sh
+ ls -l
total 8
-rwxr-xr-x 1 hudson hudson 11 Sep 27 12:09 executable
rw-rr- 1 hudson hudson 8 Sep 27 12:09 regular
Finished: SUCCESS
Here is the "build script" of test-zip-step1:
#!/bin/sh
rm -f $WORKSPACE/*
echo "regular" > $WORKSPACE/regular
echo "executable" > $WORKSPACE/executable
chmod 644 $WORKSPACE/regular
chmod 755 $WORKSPACE/executable
I'm using the Clone Workspace SCM 0.3 to move the workspace between test-zip-step1 and test-zip-step2.
Very strange. I have rechecked everything I did as thoroughly as possible.
If I unpack workspace.zip manually at the same location, using the jenkins user, test.sh does have the execute permission.
If Jenkins does it, it does not have the execute permission.
Also, I do not see any warning in the Log file, as I would expect if setting the permissions would fail.
I'm using the Clone Workspace Plugin 0.3, Jenkins 1.431.
Is it possible that some kind of security mechanism prevents java from creating files with execute permission?
After installing the jenkins-1.431.war from jenkins-ci.org, permissions no longer work when unzipping:
Started by upstream project "test-zip-step1" build number 19
Building remotely on pink
[test-zip-step2] $ /bin/sh -xe /tmp/hudson3318659544989585823.sh
+ ls -l
total 8
rw-rr- 1 hudson hudson 11 Sep 27 12:49 executable
rw-rr- 1 hudson hudson 8 Sep 27 12:49 regular
Finished: SUCCESS
I'll try a bisect later on.
Working with jenkins-1.432.war.
Maybe a testcase would help. However, I am not equipped to add one to jenkins.
Seems I'm going to stay with 1.432 for now.
Yes! I can confirm. I just updated to 1.432, and now it works. I assume that this was a bug in the ChangeLog, then. I think the bug can be closed. Thanks for the good work!
Bug is solved with 1.432. However, already 1.431 claimed to have it solved.
Not sure if I need to reopen this bug, but since the change I introduced is responsible...
My patch calls f.chmod() right after calling f.setLastModified(). This may change the last modified timestamp of the file to time of the chmod.
I apologize for the inconveniences this may have caused.
Code changed in jenkins
User: Seiji Sogabe
Path:
core/src/main/java/hudson/FilePath.java
http://jenkins-ci.org/commit/jenkins/2bd40df44439ae04ecc2db306de70230f520c1a7
Log:
Merge pull request #265 from CMoH/jenkins-9577
JENKINS-9577 Fix last modification timestamp after unzip
Integrated in jenkins_main_trunk #1180
JENKINS-9577 Fix last modification timestamp after unzip
Ciprian Ciubotariu : f967feaca9836eb4295b588482d2fba27e59e8c1
Files :
- core/src/main/java/hudson/FilePath.java
Code changed in jenkins
User: Ciprian Ciubotariu
Path:
changelog.html
core/src/main/java/hudson/FilePath.java
http://jenkins-ci.org/commit/jenkins/37a22a1cacc756fc9f1e6e6c3a0a7fa882e19944
Log:
[FIXED JENKINS-9577] Apply file permissions from zip archives
Using the zip support classes just like Ant does in order to apply
permissions. As a side-effect, remote streams need to be stored in a
temporary file before actually unzipping them.
Code changed in jenkins
User: Andrew Bayer
Path:
src/main/java/hudson/plugins/cloneworkspace/CloneWorkspacePublisher.java
src/main/java/hudson/plugins/cloneworkspace/CloneWorkspaceSCM.java
src/main/java/hudson/plugins/cloneworkspace/CloneWorkspaceUtil.java
src/main/resources/hudson/plugins/cloneworkspace/CloneWorkspacePublisher/config.jelly
src/main/webapp/archiveMethod.html
src/main/webapp/workspaceExcludeGlob.html
http://jenkins-ci.org/commit/jenkins-clone-workspace-scm-plugin/46807bc668132b4e916dd275f77fb20efc88553e
Log:
Merge pull request #1 from dkruger/master
Proposed fixes for JENKINS-9582 and JENKINS-9577
Compare: https://github.com/jenkinsci/jenkins-clone-workspace-scm-plugin/compare/8c64c38...46807bc
Code changed in jenkins
User: Andrew Bayer
Path:
src/main/java/hudson/plugins/cloneworkspace/CloneWorkspacePublisher.java
src/main/resources/hudson/plugins/cloneworkspace/CloneWorkspacePublisher/config.jelly
src/test/java/hudson/plugins/cloneworkspace/CloneWorkspaceSCMTest.java
http://jenkins-ci.org/commit/jenkins-clone-workspace-scm-plugin/a92fbe254e800b81720f91f2dcde09ffcf92b5d4
Log:
Fixing test compilation due to changes for JENKINS-9582 and JENKINS-9577.
Put in a pull request for a proposed fix: https://github.com/jenkinsci/jenkins-clone-workspace-scm-plugin/pull/1
The TarArchiver and ZipArchiver are not being used by this plugin (though I guess they could be).