Artifactory Resource

A Concourse resource to deploy and retrieve artifacts from a JFrog Artifactory server.

Overview

This Concourse resource can be used to check, deploy and retrieve artifacts from a JFrog artifactory server. It makes use of the "builds" and "artifact properties" features of Artifactory to link deployed artifacts to their builds.

Configuration

Resource Configuration

To use the artifactory-resource you must declare it in the resource_types section of your pipeline.yml file:

Resource configuration

resource_types:
- name: artifactory-resource
  type: docker-image
  source:
    repository: springio/artifactory-resource
    tag: ${releaseVersion}

Source Configuration

• uri: Required. The URI of the artifactory server

• username: Required. The artifactory username

• password: Required. The artifactory password

• build_name: Required. The name of the build

• build_number_prefix: Optional. A prefix to apply to the build number and to limit results when checking

• check_limit: Optional. The limit to the number of versions returned when performing a check

• proxy_host: The fully qualified domain name of the HTTP proxy through which the artifactory server is reachable

• proxy_port: The proxy port (required when proxy_host is specified)

Source configuration

resources:
- name: artifacts
  type: artifactory-resource
  source:
    uri: https://repo.example.com
    username: admin
    password: secret
    build_name: my-build

Environment variables

Environment variables can be referenced in any part of the configuration by using ${…​} notation. For example, typically the build_uri out parameter would be built using ${BUILD_ID}

Environment variable reference

jobs:
- name: build
  plan:
  - put: artifactory
    params:
      repo: libs-snapshot-local
      build_uri: https://my.concourse.url/builds/${BUILD_ID}

Example

The following example shows a pipeline with two jobs. The first job deploys built artifacts and the second job retrieves and runs tests against them.

Example pipeline

resource_types:
- name: artifactory-resource
  type: docker-image
  source: {repository: springio/artifactory-resource, tag: ${releaseVersion}}

resources:
- name: git-repo
  type: git
  source:
    uri: https://git.example.com/my-org/my-project
    branch: main
- name: artifactory
  type: artifactory-resource
  source:
    uri: {{ARTIFACTORY_URI}}
    username: {{USERNAME}}
    password: {{PASSWORD}}
    build_name: my-project-build

jobs:
- name: build
  plan:
  - get: git-repo
    trigger: true
  - task: build
    file: git-repo/samples/simple/tasks/build.yml
  - put: artifactory
    params:
      repo: libs-snapshot-local
      build_number: "example-${BUILD_ID}"
      folder: test
      build_uri: "{{CONCOURSE_URI}}/teams/${BUILD_TEAM_NAME}/pipelines/${BUILD_PIPELINE_NAME}"
- name: test
  plan:
  - get: artifactory
    trigger: true
    passed: [build]

Behavior

check: Check for new builds

Queries the artifactory repository for builds runs for the given build_name. Returns a list of associated build_numbers ordered by start date.

If the build_number_prefix is configured on source, the results will be restricted to only build numbers starting with that prefix.

Check operations for users without admin permissions need to download information for all build runs.
Depending on how many builds have run, this might be a significant amount of data.
The `check_limit` setting also can only be applied after data has been transfered if the user is not an admin.

If you configure your resource with an admin user, then Artifactory Query Language based queries are used which are much more efficient.

in: Fetches build artifacts

Fetches artifacts for the build run to the destination folder. The directory structure returned is identical to the one that was originally uploaded.

Fetched artifacts can also have Maven metadata generated so that the resulting folder can be used as a repository.

Files are fetch by querying for artifacts that have build.name and build.number properties associated with them. If you are querying artifacts that were not deployed with this resource, you should ensure such properties exist.

Parameters

• debug: If additional debug output should be logged.

• generate_maven_metadata: If maven meta-data should be generated. This is required if you with to use timestamp based SNAPSHOT artifacts with Maven.

• save_build_info: If the build-info.json provided by artifactory should be saved.

• download_artifacts: If artifacts should be downloaded or skipped. If you only need build-info.json you can set this to false.

• download_checksums: If artifact checksum files should be downloaded (default true).

• threads: Number of threads to use when downloading artifacts (default 1).

out: Deploy build artifacts

Deploy artifacts from the specified folder and create a new artifactory "Build Run". Uploaded artifacts will have build.name and build.number properties associated with them.

Build modules will be also automatically added when dealing with a Maven style directory structure.

Params

• debug: If additional debug output should be logged.

• repo: Required. The artifact repository to deploy to (e.g. libs-snapshot-local).

• build_number: The build number to save (if not specified, an ID based on the current date/time will be used).

• folder: The folder to save.

• include: A list of Ant style patterns for the files to include.

• exclude: A list of Ant style patterns for the files to exclude.

• module_layout: The module layout (maven or none) used to generate build-info module information (defaults to maven).

• build_uri: The URL back to the concourse build (e.g. https://my.concourse.url/builds/${BUILD_ID}).

• build_properties: A path to a UTF-8 file containing properties that should be copied into the Build-Info properties section.

• strip_snapshot_timestamps: If snapshot timestamps should be removed to allow artifactory to generate them (defaults to true).

• disable_checksum_uploads: If checksum based uploads should be disabled (useful to prevent artifactory from associating the wrong resource with a snapshot version).

• threads: Number of threads to use when deploying artifacts (defaults to 1).

• signing_key: A PGP/GPG signing key that will be used to sign artifacts (can be the key content or a reference to a file containing the key).

• signing_passphrase: The passphrase used to unlock the key.

• artifact_set: Additional configuration for a subset of the artifacts (see below).

The artifact_set parameter can be used to apply specific additional configuration to a subset of artifacts. You create sets based on include and exclude Ant patterns, then apply any of the following additional configuration:

• properties: A map of name/value pairs that will be added as properties to the deployed artifacts.

Here’s a typical example:

Artifact sets

params:
  artifact_set:
  - include:
    - "/**/*.zip"
    exclude:
    - "/**/foo.zip"
    properties:
      zip-type: docs
      zip-deployed: false