Skip to main content
Version: Early Access

Customizations for file.Folder Deployments

Customize file.Folder deployments to control how Deploy handles empty folders, performance optimization (isForceArchive), legacy behavior, connection retry logic, and debug logging.

Deploy 25.3 introduces several important updates and enhancements to file.Folder deployment behavior. The following sections outline these key changes, including new handling of empty folders and performance optimization options.

Empty Folder Handling​

In Deploy 25.3, empty folders are now included in file.Folder deployments. Previously, empty folders were excluded from deployment packages.

Force Archive Configuration​

note

The isForceArchive configuration is primarily intended for troubleshooting technical issues with file.Folder deployments. Most users should keep the default value of true for optimal performance.

Default Behavior:

  • isForceArchive is set to true by default.
  • Enables enhanced performance for folder deployments.
  • Hidden from the UI.

Switching to Legacy Behavior​

If you encounter issues with file.Folder deployments and need to revert to the behavior from Deploy 25.1 and earlier versions, you can modify the isForceArchive property.

To customize the isForceArchive property, you need to define a type modification in your synthetic.xml file:

<type-modification type="file.Folder">
    <property name="isForceArchive" default="false" hidden="true" kind="boolean" 
              category="Tar copy strategy" description="Force Archive" required="false"/>
</type-modification>

When isForceArchive is set to false:

  • Folder deployments performance degrades to pre-25.3 levels.
  • New Tar copy strategy features (stripComponents and members) remain available.

For detailed instructions on how to modify CI properties, see Tips and tricks for deployment packages.

Configuring Copy Strategy Using synthetic.xml​

You can define the default copy strategy for file.Folder deployments at the infrastructure level using synthetic.xml. This allows you to control which copy strategy (Tar, ZipUnix, ZipWindows) is used for deployments to different types of hosts.

The following examples show how to set the default copy strategy for various host types:

  • ZipUnix: Applied for deployments to overthere.SshHost

    <type-modification type="overthere.SshHost">
        <!-- Override the default copy strategy to always be ZipUnix for all "Linux" hosts -->
        <property name="copyStrategy" kind="enum" default="ZipUnix" enum-class="com.xebialabs.deployit.plugin.overthere.CopyStrategyName"/>
    </type-modification>

  • ZipWindows: Applied for deployments to overthere.BaseSmbHost

    <type-modification type="overthere.BaseSmbHost">
    <!-- Override the default copy strategy to always be ZipWindows for all "Windows" hosts -->
        <property name="copyStrategy" kind="enum" default="ZipWindows" enum-class="com.xebialabs.deployit.plugin.overthere.CopyStrategyName"/>
    </type-modification>

  • Tar: You can also set Tar as the default strategy for deployments to either host type:

    • To use Tar for deployments to Unix/Linux systems, set the following for overthere.SshHost:

      <type-modification type="overthere.SshHost">
          <property name="copyStrategy" kind="enum" default="Tar" enum-class="com.xebialabs.deployit.plugin.overthere.CopyStrategyName"/>
      </type-modification>

    • To use Tar for deployments to Windows systems, set the following for overthere.BaseSmbHost:

      <type-modification type="overthere.BaseSmbHost">
          <property name="copyStrategy" kind="enum" default="Tar" enum-class="com.xebialabs.deployit.plugin.overthere.CopyStrategyName"/>
      </type-modification>
note

Ensure the required prerequisites are met for tar or zip on your target infrastructure for the selected copy strategy to function correctly.

For more details about Copy strategies and how to choose the right one for your environment, see Copy Strategies.

Retrying Connection Establishment​

The parameter xl.task.step.on-copy-artifact.enable-retry allows the file copy process to retry connection establishment automatically, helping to recover from issues such as temporary system unresponsiveness or network disconnections.

The default value is false. If set to true, the step will retry connection establishment based on the limits defined in xl.task.step.max-retry-number and the delay specified in xl.task.step.retry-delay.

Logging​

Enable verbose logging to troubleshoot file.Folder deployments. Set the logging level to DEBUG for the following packages:

com.xebialabs.deployit.plugin.generic.step
com.xebialabs.deployit.io
com.xebialabs.deployit.io.copy

Edit conf/logback.xml and add (or adjust) the relevant logger entries.

Enabling logging

Example log output looks like this (with autodetect enabled, deploying to a Windows host):

Example log output