1

I want to replace the files whenever I deploy. Instead of replacing the existing ones, they just add up to the folder because each filenames are dynamically made.

I came across this "Remove additional files" default false and could be a solution to my problem.

However, while reading the description, the "destination" is kind of vague. Documentation here

When True instructs Web Deploy to delete files from the destination that aren't in the source package

Is the "destination" pertains to the physical path?

ZQuiray
  • 131
  • 4
  • What do you mean by "replace the files"? Do you want to clear the folder before deploying? – Alex M Aug 03 '19 at 16:25
  • Yes, But only for the items to be deployed in physical path. – ZQuiray Aug 05 '19 at 06:07
  • if you select `Custom Installation Directory` step, there will be a 'Purge` option. Otherwise I think you might need to include a pre-deployment PS script. – Alex M Aug 05 '19 at 07:53

1 Answers1

0

Yes, the destination will be the value of the Physical Path setting.

I think the setting that will be of value to you is the File comparison method. It indicates the algorithm by which comparisons will be made to determine which files, if any, should be updated by the package.

This link is to a blog post in which the Timestamp and Checksum algorithms are discussed. I have included a portion of this post below.

Timestamp instead of checksum

In Octopus 3.0 we decided to make Checksum the default (and only choice) for syncing files with WebDeploy. Using checksum we would only deploy files which had actually changed, without needing any special configuration. This reduces the time and bandwidth required for subsequent deployments to the same web app. This works really nicely for moderate sized applications but, as we discovered, becomes prohibitively slow and unreliable for large applications.

If you find yourself in this situation you can switch to using Timestamp for file comparison instead of Checksum using Octopus Deploy 3.3.3 or newer.

Timestamp

If you have any existing Azure Web App steps you will need to update them to use timestamp and create a new release. Any new Azure Web App steps you create will use timestamp by default, but you can always switch to checksum if that suits your needs better.

If you prefer checksum, we are planning to upgrade to Microsoft.Web.Deployment.3.6.0 which has several bug fixes for checksum comparisons.

Preserving timestamps

The downside with using timestamps for file comparison is reliability - you can easily get false-positives - that's why checksum is so attractive. If you are using NuGet packages the timestamp of your files will be lost when they are unpacked meaning every file appears to be newer and will be uploaded regardless of whether it has changed - more detail. To work around this, consider using zip packages - we have automated tests proving the timestamps are preserved end-to-end through your deployments.

AperioOculus
  • 6,641
  • 4
  • 26
  • 37