Is it possible for Octo.exe (or Octopack) to maintain last changed dates?

(erickt) #1

I am using octo.exe to build a package that contains CDN content that is later uploaded to S3 via the AWS comment line tool sync command. Very little changes between deployments, but because the date changed is the current date when Octopus extracts the files, it re-uploads all the files, making the deployment take a lot longer than it should. Before I start looking at workarounds, is there some way for octo.exe to maintain the last changed date for files?

Thanks,
Erick

(Michael Noonan) #2

Hi Erick,

Thanks for getting in touch. You are right, the timestamp is not preserved when System.IO.Packaging extracts the files during deployment, and this is a real pain point. Take a look at this GitHub Issue.

There are some work arounds suggested, but there is very little we can do with .nupkg extraction apart from rewriting it ourselves. I also updated that Issue mentioning some work we are doing regarding .zip packages as an alternative to .nupkg.

I’ve also raised a UserVoice Suggestion.

Hope that helps!
Mike

(erickt) #3

Hey Mike,

A zip alternative would be perfect, as long as you can still do the nice delta stuff. In the meantime, I’m writing a PowerShell script to save off the dates to a text file, then updating the dates prior to the sync.

Thanks,
Erick

(Michael Noonan) #4

Hi Erick,

Thanks for getting back to me. We’ve been specifically testing the delta compression still works with .zip and .tar.gz etc. Funnily enough we found a few incompatible libraries, in NPM for example, that write a timestamp into the zip file breaking some of the delta compression features. Rest assured we’re working around those issues, and will keep the timestamps in mind also.

Let me know how you go with the workaround.
Mike

(system) closed #6