Hi
We found that when Tentacle is unpacking NuGet packages for deployment timestamps of all files inside the package are not preserved. Is there any way to keep them? All files have correct timestamps in the package.
Hi Jimmy,
No, not presently. We believe Tentacle is in line with NuGet’s behavior here so decided not to take action on this the last time we investigated it.
Can you share a few more details of your scenario, e.g. why timestamps are important in your environment? (As opposed to versioned artifacts, etc.)
Regards,
Nick
Hi Nick,
We need to preserve timestamps for caching purposes. Our release is deployed on multiple load balanced servers.
Let’s say xap file on server A has timestamp1 and xap file on server B has timestamp2 (with timestamp1 > timestamp2). Each time the load balancing goes to server A when the previous time it went on server B it will re-download the full xap.
Jimmy Skowronski
@_jimmys
Thanks for sharing the scenario Jimmy, I’ve opened an issue here to reconsider our position on this:
https://github.com/OctopusDeploy/Issues/issues/829
Paul
Thanks. Is there anything we could do as interim solution?
Hi Jimmy,
Using a PostDeploy.ps1 script to change the file’s creation/modification attributes to a fixed value should work. There are some examples of this online, e.g. http://ss64.com/ps/syntax-touch.html
The Octopus.Deployment.Created variable will hold a consistent date when referenced from each server, so this could be a good date to choose.
Hope this helps,
Nick
Hi Paul,
Recently, we as a team were assigned with evaluating Octopus Deploy for Continuous Deployment.
I understand that this issue is closed but we had a scenario that required that the timestamp be preserved. Part of the requirements from the auditor, we have to ensure that once the applications are built, the assemblies do not changed or tempted with as they were promoted to the various environments. We have to match product version, file version as well as timestamp of each assembly. As Tentacle does not preserve the file timestamp, this leaves us in bit of a dilemma and the post deploys script “to modify the file’s attributes” does not work for us as it will be considered as tempting with the artifacts. Could we appeal to your better nature to reconsider preserving the time-stamp?
Hi Anthony,
I don’t know if you had a chance to browse the ticket mentioned in this thread.
https://github.com/OctopusDeploy/Issues/issues/829
But it looks like Paul looked into it, and there was no solution he could find.
This does mean our stance is unlikely to change.
Vanessa
Hi there,
We had exactly the same issue. XAP file behind a load balancer with a Last Mod date 1 second different between our two web servers. That caused a lot of problems with XAP being downloaded again and again.
We can get around it so it’s not a show stopper, but just wanted to point out this is still causing some pain and any movement on this one from Octopus would be received warmly.
Paul.
We were just bitten by this. We are using a post deploy script to set consistent time stamps using Octopus.Deployment.Created but unfortunately found out that if you have to redeploy to a single node in a cluster this value will be the time that deploy started. This means that the only way to rerun a deploy on one node in a cluster is to run it on all nodes on a cluster.
Fundamentally a NuGet package is a zip file. The zip file does have modification times from when the package was created. If Octopus simply preserved this time stamp on extraction instead of using the current time we would not have these problems. Setting files to the current time could simply be an option.
Hi Chris,
Thanks for getting in touch.
You’ve no doubt had a look through the referenced GitHub issue, but the only way we could do this would be to break away from NuGet and System.IO.Packaging. Early next year we’re planning to start supporting non-NuGet package types (things like zip and tar), so there’ll be an opportunity to finally overcome this issue.
Hopefully we’ll be able to close this thread with a better resolution soon!
Damo
That is good to hear although it doesn’t help with my immediate need.
I have looked at the GitHub issue but it wasn’t clear why System.IO.Packaging was the blocker. As I’ve said the NuGet package is a zip file. All the files have the timestamp of the package create time which isn’t ideal but at least it is consistent. All you would need to do is do your own unzipping.
We’ll likely start adding a text file containing the build time stamp that we can use to reset the timestamp of the files instead of the Octopus variable. The other option is to fully transition to Chocolately packages with zip file payloads (preserving all of the timestamps) and using something else for orchestration…
This is a Window OS based workaround.
To preserve the timestamp, we use the following workaround:
Zip up all deployable artifacts into a file.
Add the zip file to the NUGET package.
Create a new step template to unzip (using the default 7-zip utility that available on Window)this file on the deployed server. (This preserve the timestamp).
Hope this helps!
I admits it is rather odds placing a zip file into another zip file but it works!
That’s not a bad option. It’s basically what switching to Chocolatey would do since you typically store the main payload of what you’re installing in a separate zip file.
My misunderstanding of what Octopus.Deployment.Created is set to led us to just using the post-deploy. I wouldn’t go down that path again knowing what I know now.