{jenkins-plugin-info:pluginId=crx-content-package-deployer|jiraComponent=crx-content-package-deployer|sourceDir=crx-content-package-deployer-plugin} |
Deploys content packages to Adobe CRX applications, like Adobe CQ/AEM. Also allows downloading packages from one CRX server and uploading them to one or more other CRX servers. |
CRX login credentials are managed using functionality provided by the Credentials Plugin. Users are encouraged to provide a description for each set of credentials and to organize their credentials using Domains, which are regularly filtered by this plugin's components according to Base URL parameters. These practices reduce confusion while increasing reusability and security.
(Since 1.3) If login credentials for a 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 |
The URL in this form is ultimately parsed using the java.net.URI class, and therefore special characters should be percent-encoded before use in a Base URL field.
However, because it will be common to accept a password as a job parameter or a global parameter, and many password schemes require the use of at least one special character, not to mention those which allow any character under the sun, the user info part is first sanitized in the follow way before being parsed as a URI:
%) which are unambiguously NOT used to denote escaped ASCII characters (using the regular expression, %(?![A-Fa-f0-9]{2})) are replaced with %25." !#$\'()*+,/:;=?@[]" are replaced by a % and followed by the correct hexadecimal ASCII code.This sanitization procedure will result in correct percent-encoding of most reserved characters, and it will not over-escape input which has already been properly percent-encoded. There are a few exceptions, however:
:)./).%) followed by two characters in the space of hexadecimal digits ([A-Fa-f0-9]{2}), because this sequence will be interpreted as an escaped ASCII character and left unchanged prior to parsing by java.net.URI.Once parsed, the user info part will be stripped from the base URL before it is used by this plugin's components, to prevent credentials from being leaked in the console log. However, care should always be taken when passing credentials through Jenkins parameters in case they are exposed in other areas of the application. In addition, the Base URL field is persisted as plaintext on disk, so any unencrypted passwords stored in that field are visible to anyone who has access to the Jenkins filesystem. Use the Password Parameter type and the Mask Passwords Plugin whenever possible to properly secure your parameterized CRX application credentials.
In addition to username/password login, this plugin also supports HTTP Signature client authentication using SSH User Private Key credentials, which in turn is provided by SSH Credentials Plugin. The server side of this functionality can be setup in Adobe Granite/CRX servers by installing the Sling HTTP Signature Authentication Handler.
See also:
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:
+ or - defines an include or exclude rule, respectively.+ or - must be a valid regular expressionContent 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
|
The "Deploy Content Packages to CRX" build step can be added to any job type to upload and install CRX content packages from the workspace, or a local directory, if specified. The logic is designed to be flexible in regards to how the package files are created and organized within the directory, because it will recursively scan and identify any files which have a ".jar" or ".zip" extension. Feel free to use this step immediately after a maven build, or after the "Download Content Packages from CRX" step, or after resolving maven artifacts from a repository manager into the workspace. Once a package has been identified (i.e. has a valid group:name:version), the package will be checked against the Package ID filter to determine whether it must be uploaded to the configured Base URL(s).
If a package installation succeeds with errors "(check logs!)", the build will be marked as unstable.
The CRX Content Package Choice Parameter is a build parameter which allows a user to select any number of content
packages available for download from a CRX server as as a valid, newline-separated Package Id field value, which can
then be used in other components provided by this plugin.
The "Download Content Packages from CRX" build step can be used on any job type to download content packages to the workspace. Use the CRX Content Package Choice Parameter to select one or more packages from a live CRX Package Manager service. Downloaded packages are organized according to their CRX installation path, relative to the workspace path, or local directory, if specified.
The "Replicate Content Packages from CRX" build step can be used on any job type to asynchronously replicate content packages from one or more Granite servers to their configured replication targets, such as AEM publish servers. Use the CRX Content Package Choice Parameter to select one or more packages from a live CRX Package Manager service. This is probably not the most deterministic way to install packages on publish servers, so prefer using the "Deploy Content Packages to CRX" step whenever possible.
Create and build a content package on CRX by specifying a workspace filter, and then download it to the workspace to get archived as a backup, or as the beginning of a magical content package adventure, full of drama, suspense, and deployments to lower environments!
Validate that content packages in the workspace conform to restrictions on AC Handling Mode, Filter Root Path Prefixes, Path Inclusion, as well as to restrictions on the scope of their WorkspaceFilter and on the types of embedded files. Use this to enforce security policies to prevent developers from deploying content or code through continuous integration. Only package files with .zip or .jar extensions will be identified and validated.
crxBuild, crxDeploy, crxDownload, crxReplicate, and crxValidate symbols.