If the build agent has access to the internet, JFrog CLI and the Maven Extractor are downloaded and installed automatically on the agent the first time they are required.
If your agent has no internet access, you can configure the pipeline to download JFrog CLI and the Maven Extractor from an Artifactory instance, which is configured to proxy Bintray.
The extension runs JFrog CLI in the background to run many of its operations. The extension automatically downloads and installs the JFrog CLI on the build agent the first time it's required. However, if your build agent does not have access to the internet, the build will fail when attempting to download JFrog CLI and you'll need to download and install it manually.
To install JFrog CLI on an agent with no internet access:
In plugin versions prior to 1.8.2, JFrog CLI manual installation path is: $(Agent.WorkFolder)/_jfrog/current/ |
When triggering the Artifactory Maven task, JFrog CLI automatically downloads the Maven Extractor jar to the build agent the first time it's required. However, if your build agent does not have access to the internet, the build will fail when attempting to download the file. You'll therefore need to download and install it manually.
To install the Maven Extractor jar on an agent with no internet access:
In plugin versions prior to 1.8.2, Maven Extractor's manual installation path is: $(Agent.WorkFolder)/_jfrog/.jfrog/dependencies/maven/2.13.13 |
For the build agent to be able to run conan builds, do the following:
The build agent requires using Node.JS version 8 and above. To check which version of Node.JS is running on the build agent:
To upgrade Node.JS on the build agent:
To allow your builds to work with Artifactory, you'll need to configure your Artifactory instance as a Service Connection.
This section is relevant for you, if you're not using a public CA (Certificate Authority) to issue the SSL certificate used to connect to your Artifactory domain. You may not be using a public CA either because you're using self-signed certificates or you're running your own PKI services in-house (often by using a Microsoft CA).
In this case, you'll need to make those certificates available for JFrog CLI, which is used by most of Artifactory tasks. To make the certificates available for JFrog CLI, you'll need to place them inside the security/certs directory, which is under JFrog CLI's home directory. The home directory default location is $(Agent.ToolsDirectory)/_jfrog
Read more about this in the JFrog CLI documentation.
Make sure that the URL of the Artifactory instance does not end with a slash.
Still can't access Artifactory?
For security reasons, Artifactory SaaS supports only TLS 1.2. Since not all TFS versions support TLS 1.2, you may need to enable TLS 1.2 on TFS.
To enable TLS 1.2 on TFS:
1. Create a file and name and name it: Microsoft.PowerShell_profile.ps1
2. Add the following line to the file:
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 |
3. Place the file in the following location on the TFS machine: C:\Users\<username>\Documents\WindowsPowerShell
Make sure <username> matches the name of the user running TFS and the build agents. |
The Artifactory Generic Download task supports downloading your build dependencies from Artifactory to the build agent.
The task triggers JFrog CLI to perform the download in the background and is defined using File Specs and can also be configured to capture the build-info.
The task stores the downloaded files as dependencies in the build-info which can later be published to Artifactory using the Artifactory Publish Build-Info task.
When configuring the task, do the following:
The Artifactory Generic Upload task supports uploading your generated build artifacts from the build agent's local file system to Artifactory.
The task triggers JFrog CLI to perform the upload in the background.
The artifacts are defined using File Specs and can also be configured to capture build-info as it stores the uploaded files as artifacts in the build-info. The captured build-info can be later published to Artifactory using the Artifactory Publish Build-Info task.
When configuring the task, do the following:
Artifactory allows you to place properties on files. Setting (and deleting) properties is supported by local repositories or local-cache repositories. While you cannot set or delete properties on virtual repositories, you can retrieve them.
The Artifactory Properties task supports setting and deleting properties on files using File Specs.
For more information about managing properties in Artifactory, see Properties.
You can trigger the following builds.
The Artifactory Maven task allows triggering Maven builds, while resolving dependencies and deploying artifacts from and to Artifactory.
The task can also be configured to capture build-info and store the downloaded and uploaded artifacts as build dependencies and build artifacts. The captured build-info can be later published to Artifactory using the Artifactory Publish Build-Info task.
For more information about Maven repositories, see Artifactory Maven Repository.
The Artifactory Gradle task allows triggering Gradle builds, while resolving dependencies and deploying artifacts from and to Artifactory.
The task can also be configured to capture build-info and store the downloaded and uploaded artifacts as build dependencies and build artifacts. The captured build-info can be later published to Artifactory using the Artifactory Publish Build-Info task.
The Artifactory Npm task allows triggering npm builds, while resolving npm dependencies and deploying npm packages from and to Artifactory.
The task can be also configured to capture build-info and store the uploaded files as artifacts in it. The captured build-info can be later published to Artifactory using the Artifactory Publish Build-Info task.
For information on npm repositories, see Artifactory npm Registry.
The Artifactory Nuget and Artifactory .NET Core tasks allow restoring NuGet packages from Artifactory. These tasks also allow publishing NuGet packages to Artifactory. The tasks can be configured to capture build-info. The build-info stores the restored packages as build dependencies and uploaded packages as build artifacts. The captured build-info can be later published to Artifactory using the Artifactory Publish Build-Info task.
For more information about Nuget repositories, see Artifactory NuGet Repositories.
The Artifactory Pip task allows installing Pip packages from Artifactory. The tasks can also be configured to capture build-info. The build-info stores the installed packages as build dependencies. The captured build-info can be later published to Artifactory using the Artifactory Publish Build-Info task.
Recording all dependencies as part of the build-info
When running the Artifactory Pip task inside a Python environment, which already has some of the packages installed, the installed packages will not be included as part of the build-info, if they were not originally installed from Artifactory. A warning message will be added to the build log in this case.
How to include all packages in the build-info?
Running the task for the first time with the Disable local pip cache option checked, should re-download and install these packages, and they will therefore be included in the build-info. It is also recommended to run the command from inside a virtual environment. The Virtual environment setup command field allows this.
Behind the scenes, the task uses JFrog CLI as a wrapper for pip. JFrog CLI also includes a caching mechanism, which stores the details of the dependencies locally, making sure they are included in the build-info, even if they are already cached locally. Read more about this here.
Conan is a package manager for C and C++.
The Artifactory Conan task allows triggering a conan build while resolving conan dependencies from a conan repository in Artifactory. It also allows publishing conan packages to an Artifactory conan repository. The task can be also configured to capture build-info and store the downloaded and uploaded packages as build dependencies and artifact. The captured build-info can be later published to Artifactory using the Artifactory Publish Build-Info task.
The tasks supports the config install, add remote, create and upload conan commands. In addition, it supports a custom option, allowing to configure the task to execute any conan command. The full documentation of cona is available at the conan web site.
For more information about Conan repositories, see Artifactory Conan Repositories.
The Artifactory Go task allows triggering a go build, while resolving go dependencies from a go repository in Artifactory. It also allows publishing go packages to an Artifactory go repository. The task can be also configured to capture build-info and store the downloaded and uploaded packages as build dependencies and artifact. The captured build-info can be later published to Artifactory using the Artifactory Publish Build-Info task.
For more information about Go repositories, see Artifactory Go Repositories.
The Artifactory Docker task allows pushing and pulling docker images to and from a docker repository in Artifactory. The task can be also configured to capture build-info for the pushed or pulled image. In addition to details about the build and the build environment, the build info includes the image layers as build dependencies and build artifacts. The task stores build info locally on the build agent. The stored build-info can be later published to Artifactory using the Artifactory Publish Build-Info task.
For more information about Docker and Artifactory, see Artifactory Docker Registry.
Being able to look at the build which was published to Artifactory, and see all JIRA issues associated with it, is one of the most powerful capabilities of Artifactory when it comes to managing metadata about artifacts builds.
The Artifactory Collect Build Issues task collects the list of tracked project issues (for example, issues stored in JIRA or any other bug tracking systems, and adds these issues to the build-info. The issues are collected by reading the git commit messages from the local git log. Each commit message is matched against a pre-configured regular expression, which retrieves the issue ID and issue summary. The information required for collecting the issues is retrieved from a yaml configuration, which is set as part fo the task.
Here's the yaml configuration structure.
version: 1 issues: trackerName: JIRA regexp: (.+-[0-9]+)\s-\s(.+) keyGroupIndex: 1 summaryGroupIndex: 2 trackerUrl: http://my-jira.com/issues aggregate: true aggregationStatus: RELEASED |
Property name | Description |
---|---|
Version | The schema version is intended for internal use. Do not change! |
trackerName | The name (type) of the issue tracking system. For example, JIRA. This property can take any value. |
regexp | A regular expression used for matching the git commit messages. The expression should include two capturing groups - for the issue key (ID) and the issue summary. In the example above, the regular expression matches the commit messages as displayed in the following example: HAP-1007 - This is a sample issue |
keyGroupIndex | The capturing group index in the regular expression used for retrieving the issue key. In the example above, setting the index to "1" retrieves HAP-1007 from this commit message: HAP-1007 - This is a sample issue |
summaryGroupIndex | The capturing group index in the regular expression for retrieving the issue summary. In the example above, setting the index to "2" retrieves the sample issue from this commit message: HAP-1007 - This is a sample issue |
trackerUrl | The issue tracking URL. This value is used for constructing a direct link to the issues in the Artifactory build UI. |
aggregate | Set to true, if you wish all builds to include issues from previous builds. |
aggregationStatus | If aggregate is set to true, this property indicates how far in time should the issues be aggregated. In the above example, issues will be aggregated from previous builds, until a build with a RELEASE status is found. Build statuses are set when a build is promoted using the jfrog rt build-promote command. |
The yaml configuration can be either be stored as text as part of the task configuration, or stored in a file. The file can be saved in the source control, and fetched, together with the rest of the sources to the build agent. It can then be accesses and used by this task.
The Artifactory Generic Download and Artifactory Generic Upload tasks can be configured to collect and store build-info locally. The collected build info can be then published to Artifactory using the Artifactory Publish Build Info task.
For more information about Build Info, see Artifactory Build Integration.
When configuring the task, select your configured Artifactory service endpoints and specify whether you'd like to collect environment variables from the agent and add them to the build-info.
After the build-info is published to Artifactory, it can be accessed from the Artifactory tab in the Build Results.
To support the artifacts life-cycle, Artifactory supports promoting published builds from one repository to another.
The Artifactory Build Promotion task promotes a build, by either copying or moving the build artifacts and/or dependencies to a target repository.
This task can be added as part of a Build or Release pipeline.
Run these steps to configure the Artifactory Build Promotion task:
You can control the life cycle of your artifacts by promoting them from one Artifactory repository to another. Build Promotion can come in handy when embedding it as part of release pipeline in Azure DevOps. To help you achieve this, follow these steps for creating a release which includes the Artifactory Build Promotion task.
The Artifactory Xray Scan task allows triggering a build scan with JFrog Xray. For the build to be scanned, it first needs to be published to Artifactory using the Artifactory Publish BuildInfo task. When the scan is triggered, Artifactory will pass on the build to Xray, which will then scan the build artifacts. The scan is synchronous, meaning it will wait for the scan to finish.
If the Allow fail build task option is set and Xray is configured to fail the build, the build pipeline will fail, if vulnerabilities are found.
After the Xray scan is completed, the report can be accessed from the Artifactory tab in the Build Results.
Artifacts which were published to Artifactory can be made available for a Release Pipeline. There are two ways to achieve this.
The first way is to use the Artifactory Download task to download the files during the release. Read more about this in the Downloading Generic Dependencies from Artifactory section.
You can also set Artifactory as an artifact source for the release. This allows downloading the artifacts for a build which was previously published to Artifactory. Read more about publishing builds to Artifactory in the Publishing Build Info to Artifactory section.
Follow these steps to add Artifactory as an artifact source to a Release.
To discard old runs of a build from Artifactory, add the Artifactory Discard Builds to the pipeline.
Run these steps to configure the task.
The extension support a generic JFrog CLI task, which allows executing JFrog CLI commands. The command will use the connection details provided by the selected Artifactory service, so there's no need to provide the connection details as command options.
The task supports commands with the jfrog rt prefix.
Bug fix: Download and explode fails while inside a docker container.
Bug fix: Artifactory NuGet restore is unable to handle spaces in Destination directory.
New Artifactory Pip task.
Add support for "jfrog rt curl" by the JFrog CLI task.
Allow defining deployment path for NuGet and .Net Push.