You can deploy artifacts into a local repository of Artifactory from the Artifacts module by clicking Deploy to display the Deploy dialog. Artifacts can be deployed individually or in multiples.
Using Import to "deploy" a whole repository
If you want to "deploy" a whole repository, you should actually import it using the Import Repository feature in the Admin tab under Import & Export | Repositories.
You can also deploy Artifacts to a virtual repository using the REST API.
Deploying a Single Artifact
To deploy a single artifact, simply fill in the fields in the Deploy dialog and click "Deploy".
If you are deploying a Maven artifact, you may need to configure additional attributes as described in the next section.
Suggested Target Path
Artifactory will suggest a Target Path based on the details of your artifact (this works for both Maven and Ivy). For example, if a JAR artifact has an embedded POM under its internal
META-INF directory, this information is used.
Deploying Maven Artifacts
If you are deploying an artifact that conforms to the Maven repository layout, you should set Deploy as Maven Artifact to expose fields that specify the corresponding Maven attributes - GoupID, ArtifactID, Version, Classifier and Type.
The fields are automatically filled in according to the artifact name, however you can edit them and your changes will also be reflected in the Target Path.
If your target repository does not include a POM, set Also Deploy Jar's Internal POM/Generate Default POM, to use the POM within the artifact you are deploying, or generate a default POM respectively.
Take care when editing the POM manually
If you are editing the POM manually, be very careful to keep it in a valid state.
Deploying with Properties
Properties can be attached to the uploaded file by specifying them on the Target Path.
First, unset the Deploy as Maven Artifact check box, if necessary.
Then, in the TargetPath field, add the properties delimited from the path and from each other by semicolons. Each property is a
For example, to upload an artifact with the property qa set to "passed", and build.number set to "102", use the following Target Path:
Deploying Multiple Files
To deploy multiple files together, simple set the deploy Type to Multi, fill in the rest of the fields in the dialog and click "Deploy".
Deploying an Artifact Bundle
An artifact bundle is deployed as a set of artifacts packaged in an archive with one of the following supported extensions: zip, tar, tar.gz, tgz.
When you specify that an artifact should be deployed as a bundle, Artifactory will extract the archive contents when you deploy it.
File structure within the archive
Artifacts should be packaged within the archive in the same file structure with which they should be deployed to the target repository.
To deploy an artifact bundle, in the Deploy dialog, first upload the archive file you want to deploy.
Check the Deploy as Bundle Artifact checkbox and click Deploy.
Deploying to a Virtual Repository
From version 4.2, Artifactory supports deploying artifacts to a virtual repository.
To enable this, you first need to designate one of the local repositories that is aggregated by the virtual repository as a deployment target. This can be done through the UI by setting the Default Deployment Repository in the Basic Settings of the Edit Repository screen.
You can also set the Default Deployment Repository using the
defaultDeploymentRepo parameter of the Virtual Repository Configuration JSON used in the Create or Replace Repository Configuration and Update Repository Configuration REST API endpoints. Once the deployment target is configured, you may deploy artifacts to it using any packaging format client configured to work with Artifactory. For example,
docker push, npm publish, NuGet push, gem push etc.
You can also use Artifactory's REST API to deploy an artifact and use the virtual repository key in the path to deploy.
The most common reasons for a rejected deployment are:
- Lack of permissions
- A conflict with the target repository's includes/excludes patterns
- A conflict with the target repository's snapshots/releases handling policy.