SCP Remote File plugin

The SCP Remote File plugin is a project plugin that is used to integrate the framework with a remote filesystem for storage of a projects built artifacts.

When an artifact request is made, the following actions are performed:

  • Check on the local filesystem buildstore path for the artifact and if found use this location.
  • Check on the remote repository for the artifact, if found copy it to the local buildstore.
  • Check on the build servers in the order specified in the field and if the artifact is found, copy it to the local buildstore and the remote repository (unless the remote repository is empty or cannot be accessed).
  • Download the manifest file (file suffix - buildstore.manifest), update the contents then upload it back to the build store.
  • If the package has been downloaded from the repository then download the manifest and then test the file checksums. If the checksums are different then the raise an error.
  • If the manifest file does not exist then it is generated and uploaded to the buildstore. The manifest file has the following contents (filename checksum isProduction).

Each server is referenced by the display name given in the server administration page. The connection details and the build store locations are also defined in the server administration page.

About deployable packages

RapidDeploy stores all of its deployable artifacts as versioned packages in jar, tar or zip format. Depending on the project configuration, each package will contain:

  1. Code only package
    1. All of the built code (for example ear, war, jar files)
    2. Properties files to update the built artifacts with environment specific values
    3. The configuration, for each defined target environment, to build from scratch or update this applications dependent container resources such as Database or JMS Providers
  2. Code and configuration package
    1. All of the built code (for example ear, war, jar files)
    2. Properties files to update the built artifacts with environment specific values
    3. The configuration, for each defined target environment, to build from scratch or update the environment (for example create or update a WebSphere cluster and dependent container resources such as Database or JMS Providers).
  3. Configuration only package (configuration only projects)
    1. The configuration, for each defined target environment, to build from scratch or update the environment (for example create or update a WebSphere cluster and any shared resources such as Database or JMS providers).

    The name of the package is usually derived from the label or baseline created in the SCM repository during the build or continuous integration process used to build the deployable code and/or configuration.

Attributes and parameters

List and description of all user interface plugin parameters..