Published: Sep 20, 2019 by Isaac Johnson
One of the more interesting offerings that was presented at HashiConf 2019 came from the JFrog vendor booth - makers of Artifactory, one of the two leading binary artifact storage and dissemination tools (the other being Sonatype Nexus). They told me they now have (in beta) CI/CD pipelines. This I had to try…
Sign-up
First, go to the free-trial pageand sign up for the GCP Sandbox demo
After jumping through a few captcha hoops, you’ll finally get presented to your sandbox environment:
Click “Launch Test Drive” and this will create Artifactory, Xray and… Jenkins.
Deflated
Really.. Junkins? That’s their big “CI/CD” innovation? Not even a unique port.. Just the standard 8086…
The PDF clues us in later:
Why? So it’s Jenkins, but can we learn something?
Try it anyways
To start with, it wants to build https://github.com/jfrogtraining/project-examples.git from branch eplus-orbitera. Let’s try this locally.
Looks like we need to install gradle
Refresh env and try again;
But as many times as i tried to build and publish, no luck. I tried downgrading to gradle 3.3 as well.
Errors about not having an artifactoryPublish kept pestering me…
C:\Users\isaac\Documents\Workspaces\project-examples\tutorial\step1-create-gradle-app>D:\gradle-3.3\bin\gradle clean artifactoryPublish -b ./build.gradle
Starting a Gradle Daemon (subsequent builds will be faster)
FAILURE: Build failed with an exception.
* What went wrong:
Task 'artifactoryPublish' not found in root project 'frogsws'.
* Try:
Run gradle tasks to get a list of available tasks. Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
BUILD FAILED
Total time: 8.592 secs
I manually added it
C:\Users\isaac\Documents\Workspaces\project-examples\tutorial\step1-create-gradle-app>git diff
diff --git a/tutorial/step1-create-gradle-app/build.gradle b/tutorial/step1-create-gradle-app/build.gradle
index 790c6b1..546a7b8 100644
--- a/tutorial/step1-create-gradle-app/build.gradle
+++ b/tutorial/step1-create-gradle-app/build.gradle
@@ -14,6 +14,7 @@ buildscript {
dependencies {
classpath("org.springframework.boot:spring-boot-gradle-plugin:${springBootVersion}")
classpath("io.spring.gradle:dependency-management-plugin:0.6.0.RELEASE")
+ classpath("org.jfrog.buildinfo:build-info-extractor-gradle:latest.release")
}
}
@@ -21,6 +22,7 @@ apply plugin: 'groovy'
apply plugin: 'eclipse'
apply plugin: 'idea'
apply plugin: 'spring-boot'
+apply plugin: "com.jfrog.artifactory"
But still no luck.
Trying with Azure DevOps
Let’s go another route.. Can we use the artifactory instance in AzDO?
Let’s take a basic Maven build
Let’s add the settings from Artifactory:
In a sample maven project we can add
<distributionManagement>
<repository>
<id>temp-artifactory-snap</id>
<url>http://34.68.160.182/artifactory/libs-snapshot-local</url>
<releases>
<enabled>false</enabled>
</releases>
<snapshots>
<enabled>true</enabled>
</snapshots>
</repository>
<repository>
<id>temp-artifactory-rel</id>
<url>http://34.68.160.182/artifactory/libs-release-local</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
</distributionManagement>
And in our build file, add a block to create an inline settings:
#!/bin/bash
set -x
umask 0002
cat > $BUILD_SOURCESDIRECTORY/cicd-settings.xml <<'endmsg'
<settings>
<servers>
<server>
<id>temp-artifactory-snap</id>
<username>admin</username>
<password>xxxxxxxxxxxx</password>
</server>
<server>
<id>temp-artifactory-rel</id>
<username>admin</username>
<password>xxxxxxxxx</password>
</server>
</servers>
</settings>
Endmsg
Then change your mvn invokation to include deploy:
clean install deploy --settings $(Build.SourcesDirectory)/cicd-settings.xml
Once we build, we can see Maven deployed successfully to our repo:
And we can see it reflected in Artifactory in multiple places:
The sample Artifactory they lent us has repositories set up for all sorts of things including docker containers.
Summary:
Artifactory is a very interesting offering and worth digging deeper. However bundling Jenkins, while convenient, isn’t really awe-inspiring.