Specify a list of package IDs to replicate from each specified Base URL. Each package ID string must occupy its own line.

A Package ID consists of the group, the name, and the version of a package, separated by colons (':'), as in: "group:name:version". The version may be omitted.

This field supports parameter tokens.

Specify the base URL of the Adobe Granite server, including hostname and port. The CRX Package Manager service path will be appended to this value for all requests. For example, http://localhost:4502 or https://author.mycorp.com, etc.

If login credentials for the server are different than those configured in the Connection Options section, you may override them in the Base URL by inserting username[:password]@ between the scheme and the hostname.

For example, to override the Username without changing the associated password or private key, you may use the following form:

http://deployer@localhost:4502

To override the credentials completely, provide a username and password (which may be provided by an encrypted parameter) by separating them with a colon, as shown below:
http://deployer:Password123@localhost:4502

This field supports parameter tokens.

Select the login credentials for authenticating requests to the CRX server.

[Signature] credentials may be used if the target server supports HTTP Signature Authentication using the keyId format, /$username/keys/$fingerprint.

Select "-none-" to use the default credentials set in the global CRX Content Package Deployer - HTTP Client configuration.

Check this box to download the package after building it.

Specify a path relative to the workspace where the package will be downloaded (if the "Download" box is checked).

This field supports parameter tokens.

Specify the timeout in milliseconds to wait for a response for each individual request. Specify a value of 0 to use default behavior.

Specify the timeout in milliseconds to wait for PackageManager service availability between sending POST requests. Specify a value of 0 to use default behavior.

Specify a delay in milliseconds before calls to check for Package Manager service availability. Increase this value if a /crx/packmgr node is sometimes created in the repository by this step, indicating that the Package Manager servlet was brought down for bundle installation AFTER a successful check for service availability, but BEFORE the next POST request was sent. What happens is that the SlingPostServlet takes over when the crx-packagemgr bundle is refreshed and creates nodes for any POST requests that it handles. Increasing this delay gives more time for the bundle refresh process to begin on the server.

Specify a package workspace filter in a simple text format that will be applied to the package before build. This defines what content will be captured by the package.

Simple spec is defined simply as a line-by-line format where:

• each line consists of significant text before an optional comment character (#)
• each line that begins with a "/" begins a new filter root.
• the first non-empty, non-comment line must define a new filter root
• each non-empty, non-comment line after a filter root that begins with a "+" or "-" defines an include or exclude rule, respectively. Everything following the "+" or "-" must be a valid regular expression

Content is "covered" by a filter root if the content path starts with, or is the same as the filter root path. Once the "covering" filter root is identified, its include/exclude rules are evaluated from top to bottom, by matching the content path against each rule pattern (which is a Java regular expression). The last rule whose pattern matches the content path defines whether that content is included (line starts with "+") or excluded (line starts with "-"). If no rules are defined, all content covered by that root path is included

For example, to include everything under /etc except for packages:

        /etc                 # define /etc as the filter root
        +/etc(/.*)?          # include everything under /etc
        -/etc/packages(/.)?  # exclude package paths
    

To create a package for a project "acme" defined in CRX DE Lite, a filter may look like this:

        /content/acme        # include the site content
        /apps/acme           # include the app code
    

This field supports parameter tokens.

Specify a list of package ID filters and path filters to match against identified Vault packages located in the workspace. Each filter string must occupy its own line.

A Package ID consists of the group, the name, and the version of a package, separated by colons (':').
Package ID filters must follow one of three patterns:

• group:name:version
• group:name
• name

Each segment in the package ID filter may be either ommitted or replaced with an asterisk ('*') to represent a wildcard.

This step now supports path filters as well. A path filter is a path suffix relative to the localDirectory ending in '.zip' or '.jar', which may include '**', '*', and '?' wildcard characters.

For example, this pattern will match all zip files under the Local Directory:

        **/*.zip
    

This pattern will only match packages located directly under the Packages folder whose filenames begin with 'acme-':

        Packages/acme-*.zip
    

Matching packages will be uploaded in the order in which the filters are specified. Only the highest matching version of a package identified by 'group:name' will be deployed, and it will only be deployed once per build step, regardless of the number of matching filters.

This field supports parameter tokens.

Specify the base URL of the Adobe Granite server, including hostname and port. The CRX Package Manager service path will be appended to this value for all requests. For example, http://localhost:4502 or https://author.mycorp.com, etc.

Multiple urls can be specified, one per line. All specified packages will be deployed to one server before beginning deployments to the next one.

If login credentials for one of the servers are different than those configured in the Connection Options section, you may override them in the Base URL by inserting username[:password]@ between the scheme and the hostname.

For example, to override the Username without changing the associated password or private key, you may use the following form:

http://deployer@localhost:4502

To override the credentials completely, provide a username and password (which may be provided by an encrypted parameter) by separating them with a colon, as shown below:

http://deployer:Password123@localhost:4502

This field supports parameter tokens.

Change the way content ACL's included in the package filter scope are handled during installation.

Defer to Package

Allow package to specify AC Handling mode. (This can be dangerous. Consider using a Validate CRX Content Packages step to check packages for destructive AC Handling rules before you deploy them.)

Ignore

Ignores the packaged access control and leaves the target unchanged.

MergePreserve

Merge access control in the content with the one provided with the package by adding the access control entries of principals not present in the content (i.e. content first). It never alters access control entries already existing in the content.

Merge

Merge access control provided with the package with the one in the content by replacing the access control entries of corresponding principals (i.e. package first). It never alters access control entries of principals not present in the package.

Overwrite

Applies the access control provided with the package to the target. This also removes existing access control.

Clear

Clears all access control on the target system.

Specify the number of changes to batch before saving the JCR session during package installation.

Specify the behavior when a package exists on the target server that has the same package ID as one you are trying to deploy.

Select the login credentials with which content packages will be deployed to the CRX server.

[Signature] credentials may be used if the target server supports HTTP Signature Authentication using the keyId format, /$username/keys/$fingerprint.

Select "-none-" to use the default credentials set in the global CRX Content Package Deployer - HTTP Client configuration.

Check this box to disable package deployment during Jenkins Job testing. For example, it is often necessary to test changes to artifact resolution configuration or to test Vault package identification. By checking this box, you can be sure that no installation will occur on any Granite server, and you will also see additional debug messaging in the console log describing the results of identification of Vault packages in the workspace.

Specify a path relative to the workspace in which to scan for packages.

This field supports parameter tokens.

Check this box to install any sub-packages along with the deployed package.

Check this box to replicate each package after installation. This will not be attempted if the package installation fails, and only packages which have actually been installed by this step (rather than simply uploaded or skipped) will be replicated. This happens asynchronously, so you won't really know if the replication was successful or not unless you manually check your replication agent logs. For this reason, it might be better instead to deploy to each replication target directly.

Specify the timeout in milliseconds to wait for a response for each individual request. Specify a value of 0 to use default behavior.

Specify the timeout in milliseconds to wait for PackageManager service availability between sending POST requests. Specify a value of 0 to use default behavior.

Specify a delay in milliseconds before calls to check for Package Manager service availability. Increase this value if a /crx/packmgr node is sometimes created in the repository by this step, indicating that the Package Manager servlet was brought down for bundle installation AFTER a successful check for service availability, but BEFORE the next POST request was sent. What happens is that the SlingPostServlet takes over when the crx-packagemgr bundle is refreshed and creates nodes for any POST requests that it handles. Increasing this delay gives more time for the bundle refresh process to begin on the server.

Specify a list of package IDs to download to the workspace. Each package ID string must occupy its own line.

A Package ID consists of the group, the name, and the version of a package, separated by colons (':'), as in: "group:name:version".

This field supports parameter tokens.

Specify the base URL of the Adobe Granite server, including hostname and port. The CRX Package Manager service path will be appended to this value for all requests. For example, http://localhost:4502 or https://author.mycorp.com, etc.

If login credentials for the server are different than those configured in the Connection Options section, you may override them in the Base URL by inserting username[:password]@ between the scheme and the hostname.

For example, to override the Username without changing the associated password or private key, you may use the following form:

http://deployer@localhost:4502

To override the credentials completely, provide a username and password (which may be provided by an encrypted parameter) by separating them with a colon, as shown below:

http://deployer:Password123@localhost:4502

This field supports parameter tokens.

Select the login credentials with which content packages will be downloaded from the CRX server.

[Signature] credentials may be used if the target server supports HTTP Signature Authentication using the keyId format, /$username/keys/$fingerprint.

Select "-none-" to use the default credentials set in the global CRX Content Package Deployer - HTTP Client configuration.

Check this box to ignore errors during download such that the build continues after completion of this step.

Specify a path relative to the workspace to which packages will be downloaded.

This field supports parameter tokens.

Check this box to rebuild each package before downloading it. If rebuilding a package fails, the job will fail, unless Ignore Errors is also checked. If there are errors during rebuild, but it is ultimately reported as successful, then the job will be marked as unstable and the download step will continue.

Specify the timeout in milliseconds to wait for a response for each individual request. Specify a value of 0 to use default behavior.

Specify the timeout in milliseconds to wait for PackageManager service availability between sending POST requests. Specify a value of 0 to use default behavior.

Specify a delay in milliseconds before calls to check for Package Manager service availability. Increase this value if a /crx/packmgr node is sometimes created in the repository by this step, indicating that the Package Manager servlet was brought down for bundle installation AFTER a successful check for service availability, but BEFORE the next POST request was sent. What happens is that the SlingPostServlet takes over when the crx-packagemgr bundle is refreshed and creates nodes for any POST requests that it handles. Increasing this delay gives more time for the bundle refresh process to begin on the server.

Specify a list of package IDs to replicate from each specified Base URL. Each package ID string must occupy its own line.

A Package ID consists of the group, the name, and the version of a package, separated by colons (':'), as in: "group:name:version".

This field supports parameter tokens.

Specify the base URL of the Adobe Granite server, including hostname and port. The CRX Package Manager service path will be appended to this value for all requests. For example, http://localhost:4502 or https://author.mycorp.com, etc.

Multiple urls can be specified, one per line. All specified packages will be replicated from one server before beginning replications from the next one.

If login credentials for one of the servers are different than those configured in the Connection Options section, you may override them in the Base URL by inserting username[:password]@ between the scheme and the hostname.

For example, to override the Username without changing the associated password or private key, you may use the following form:

http://deployer@localhost:4502

To override the credentials completely, provide a username and password (which may be provided by an encrypted parameter) by separating them with a colon, as shown below:

http://deployer:Password123@localhost:4502

This field supports parameter tokens.

Select the login credentials with which content packages will be replicated from the CRX server.

[Signature] credentials may be used if the target server supports HTTP Signature Authentication using the keyId format, /$username/keys/$fingerprint.

Select "-none-" to use the default credentials set in the global CRX Content Package Deployer - HTTP Client configuration.

Check this box to ignore errors during replication such that the build continues after completion of this step.

Specify the timeout in milliseconds to wait for a response for each individual request. Specify a value of 0 to use default behavior.

Specify the timeout in milliseconds to wait for PackageManager service availability between sending POST requests. Specify a value of 0 to use default behavior.

Specify a delay in milliseconds before calls to check for Package Manager service availability. Increase this value if a /crx/packmgr node is sometimes created in the repository by this step, indicating that the Package Manager servlet was brought down for bundle installation AFTER a successful check for service availability, but BEFORE the next POST request was sent. What happens is that the SlingPostServlet takes over when the crx-packagemgr bundle is refreshed and creates nodes for any POST requests that it handles. Increasing this delay gives more time for the bundle refresh process to begin on the server.

Specify a list of package ID filters to match against identified Vault packages located in the workspace. Each filter string must occupy its own line.

A Package ID consists of the group, the name, and the version of a package, separated by colons (':').

Package ID filters must follow one of three patterns:

• group:name:version
• group:name
• name

Each segment in the package ID filter may be either ommitted or replaced with an asterisk ('*') to represent a wildcard.

This step now supports path filters as well. A path filter is a path suffix relative to the localDirectory ending in '.zip' or '.jar', which may include '**', '*', and '?' wildcard characters.

For example, this pattern will match all zip files under the Local Directory:

        **/*.zip
    

This pattern will only match packages located directly under the Packages folder whose filenames begin with 'acme-':

        Packages/acme-*.zip
    

Matching packages will be validated in the order in which the filters are specified. At least one package must match each filter or the step will fail.

This field supports parameter tokens.

Check this box to allow package workspace filters to cover roots which are not covered by the validation workspace filter.

Select a set of AC Handling Modes to forbid, to prevent destructive or unauthorized changes to Access Control Lists, at the package level:

Skip Validation

Do not validate package AC Handling Mode.

No Clear

Forbid the "Clear" AC Handling Mode, which resets all covered ACLs (Forbids "Clear").

No Unsafe

Forbid any AC Handling Mode which may delete ACLs for unspecified users (Forbids "Clear", "Overwrite").

Allow Additive

Forbid any AC Handling Mode which may delete or overwrite an existing ACL (Forbids "Clear", "Overwrite", "Merge").

No ACLs

Forbid any AC Handling Mode other than "Ignore" (Forbids "Clear", "Overwrite", "Merge", "MergePreserve").

List of file extensions to scan the package for (as a jar file), one per line. For example, specify the following to ensure that embedded jar files and package files are not included in the package even if the workspace filter does not cover the paths from where they could be theoretically installed:

        .jar
        .zip
    

This field supports parameter tokens.

List of path prefixes which are forbidden to be the same path or an ancestor of any workspace filter root. Surrounding whitespace and trailing slashes are ignored and the prefix is treated as an atomic path. For example:

/apps/system

will fail a package defining a filter root of

/apps/system/config

but it will not fail a package filter covering only

/apps/systemOfADown/config

Use this test to safeguard entire repository trees from package installation or uninstallation.

This field supports parameter tokens.

Specify a path relative to the workspace in which to scan for packages to validate.

This field supports parameter tokens.

List of test paths which must be "excluded" by the package filter in order to be considered valid. For example:

        /apps/system/rep:policy
        /etc/map/http/site_root_redirect
    

Use this test to safeguard specific paths or possible paths within unrestricted roots from overly broad workspace filters.

This field supports parameter tokens.

Specify a validation workspace filter in a simple text format that each package workspace filter will be evaluated against.

Simple spec is defined simply as a line-by-line format where:

• each line consists of significant text before an optional comment character (#)
• each line that begins with a "/" begins a new filter root.
• the first non-empty, non-comment line must define a new filter root
• each non-empty, non-comment line after a filter root that begins with a "+" or "-" defines an include or exclude rule, respectively. Everything following the "+" or "-" must be a valid regular expression

A package filter root is "covered" by a validation filter root if the package filter root path starts with, or is the same as the validation filter root path. Once the "covering" validation filter root is identified, the package filter root's include/exclude rules are inspected to be sure that they contain all of the validation filter's rules in order, at the end of the list.

For example, to require that packages exclude the /etc/packages folder:

        /etc                 # define /etc as the filter root
        -/etc/packages(/.)?  # exclude package paths
    

This field supports parameter tokens.