-
Bug
-
Resolution: Fixed
-
Major
-
None
-
Windows Server 2003, .NET development
We rely on date/time-stamps to deploy only the code that has changed to our various environments. While developing a deployment mechanism to deploy from the archived Hudson artifacts for a particular build, we realized that upon archival of the artifacts, Hudson sets the timestamps of all archived files to the present time (when the archiving is taking place). This is preventing us from deploying only the code that has changed.
Shouldn't Hudson preserve the timestamps when it is archiving the artifacts?
[JENKINS-7228] Archiving artifacts does not preserve timestamps
Johannes Schmieder
added a comment - Seems to be solved by JENKINS-13122 . No response from the reporter to the last comment.
So resolving this issue, which is said to be fixed.
Timmy Brolin
added a comment - I ran into the same problem.
The timestamp of all the archived artifacts is reset to the time and date they were archived.
The problem is easy to spot. Check this directory (or the equivalent on your setup):
C:\Jenkins\jobs\MyJob\builds\2014-07-01_01-01-01\archive
Note that the date and time of all files in this folder has been set to the time when they were archived.
I am trying to setup a multi-stage HDL build pipeline, where one job compiles the project, and another job performs layout.
I use CopyArtifacts to transfer the artifacts from the first to the second job.
But because the timestamp on all files are changed by jenkins, the second job detects that dependencies have changed and assumes that the project is in a pre-compile state. So it refuses to run the layout step.
The cited "JENKINS-13122" only solves this problem for the ZIP-version of artifact archiving. The problem still remains for regular uncompressed artifacts.
I cannot use compressed artifacts as a workaround, since I am using CopyArtifacts. The two are not compatible.
(We are using Jenkins 1.565)
Timmy Brolin
added a comment - I ran into the same problem.
The timestamp of all the archived artifacts is reset to the time and date they were archived.
The problem is easy to spot. Check this directory (or the equivalent on your setup):
C:\Jenkins\jobs\MyJob\builds\2014-07-01_01-01-01\archive
Note that the date and time of all files in this folder has been set to the time when they were archived.
I am trying to setup a multi-stage HDL build pipeline, where one job compiles the project, and another job performs layout.
I use CopyArtifacts to transfer the artifacts from the first to the second job.
But because the timestamp on all files are changed by jenkins, the second job detects that dependencies have changed and assumes that the project is in a pre-compile state. So it refuses to run the layout step.
The cited " JENKINS-13122 " only solves this problem for the ZIP-version of artifact archiving. The problem still remains for regular uncompressed artifacts.
I cannot use compressed artifacts as a workaround, since I am using CopyArtifacts. The two are not compatible.
(We are using Jenkins 1.565) More info: It seems to be connected to the use of artifact filter "**"
For other filters such as "myfolder**" (myfolder backslash asterisk asterisk) I get properly preserved artifact timestamps.
Is jenkins perhaps detecting "/" and "\" in the artifact filter to determine if the system is UNIX or Windows? Could this be it?
Timmy Brolin
added a comment - - edited More info: It seems to be connected to the use of artifact filter "**"
For other filters such as "myfolder**" (myfolder backslash asterisk asterisk) I get properly preserved artifact timestamps.
Is jenkins perhaps detecting "/" and "\" in the artifact filter to determine if the system is UNIX or Windows? Could this be it? Timmy Brolin
added a comment - Created a new issue for the artifact filter-dependent problem: JENKINS-23645
Timmy Brolin
added a comment - Created a new issue for the artifact filter-dependent problem: JENKINS-23645 
I have the same problem. For patch creation one job uses the artifacts of another job. This job fetches the artifacs via "get" per "http" as a zip-File. The job creates checksums from all files to be used for a later versioncheck. Every time the job fetches the artifacs they have the timestamp of the get request. That's why even these files become a new checksum although they did not change. On the filesystem of the buildserver the files have the timestamps when they have been created. That's correct. I would suppose to get the files with exactly the timestamps they have been created and not the timestamp of the download request.