Jenkins Artifactory Plugin vs. Maven



几个问题:

  1. 在凭据和插件的授权方面,我是否明显缺少一些东西
  2. 为什么pom文件上传失败,而实际工件却没有
  3. 使用Jenkins Artifactory插件而不仅仅使用Maven命令的优势是什么

我一直在尝试使用Jenkins Artifactory插件配置Jenkins管道。当到达包含rtMavenRun的步骤时,我不断遇到来自Artifactory的401响应。在日志中,我看到的是:

注意:为了简洁起见,我用替换了URL

Downloading from eti-artifacts-snapshot: http://<URL>/work-queue-api/1.1.0-SNAPSHOT/maven-metadata.xml
Uploading to eti-artifacts-snapshot: http://<URL>/work-queue-api/1.1.0-SNAPSHOT/work-queue-api-1.1.0-20200407.120051-1.jar
Progress (1): 0.5/66 MB
Progress (1): 1.0/66 MB
....
Progress (1): 64/66 MB
Progress (1): 65/66 MB
Progress (1): 66/66 MB
Progress (1): 66 MB   
Uploading to eti-artifacts-snapshot: http://<URL>/libs-snapshot/com/etisoftware/work-queue-api/1.1.0-SNAPSHOT/work-queue-api-1.1.0-20200407.120051-1.pom
Progress (1): 4.1/7.2 kB
Progress (1): 7.2 kB    
[main] INFO org.apache.maven.cli.event.ExecutionEventLogger - ------------------------------------------------------------------------
[main] INFO org.apache.maven.cli.event.ExecutionEventLogger - BUILD FAILURE
[main] INFO org.apache.maven.cli.event.ExecutionEventLogger - ------------------------------------------------------------------------
[main] INFO org.apache.maven.cli.event.ExecutionEventLogger - Total time:  01:06 min
[main] INFO org.apache.maven.cli.event.ExecutionEventLogger - Finished at: 2020-04-07T08:00:57-04:00
[main] INFO org.apache.maven.cli.event.ExecutionEventLogger - ------------------------------------------------------------------------
[main] ERROR org.apache.maven.cli.MavenCli - Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-cli) on project work-queue-api: Failed to deploy artifacts: Could not transfer artifact work-queue-api:jar:1.1.0-20200407.120051-1 from/to eti-artifacts-snapshot (http://<URL>/libs-snapshot): Transfer failed for http://<URL>/artifactory/libs-snapshot-local/com/etisoftware/work-queue-api/1.1.0-SNAPSHOT/work-queue-api-1.1.0-20200407.120051-1.jar 401 Unauthorized -> [Help 1]

请注意,它似乎正在上传jar文件,但在pom上失败了。因此,显而易见的答案似乎是用户没有上传某些内容的授权。Jenkins中的artifactory配置使用与我的m2/settings.xml文件相同的凭据。当我运行mvn clean package deploy时,它按预期工作。

然后,我将Jenkinsfile更改为直接使用mvn命令,它也像预期的那样工作。同样,这将使用settings.xml文件。

这是使用插件时的管道。这不起作用,我收到401的回复。

pipeline {
agent any
stages {
stage ('Artifactory configuration') {
steps {
rtMavenDeployer (
id: "RT_MAVEN_DEPLOYER",
serverId: "ETI_ARTIFACTORY",
releaseRepo: "libs-release-local",
snapshotRepo: "libs-snapshot-local"
)
rtMavenResolver (
id: 'RT_MAVEN_RESOLVER',
serverId: 'ETI_ARTIFACTORY',
releaseRepo: 'libs-release',
snapshotRepo: 'libs-snapshot'
)   
}
}        
stage('Maven exec') { 
steps {
rtMavenRun (
pom: 'pom.xml',
goals: 'clean package deploy',
tool: 'M2_TOOL',
resolverId: 'RT_MAVEN_RESOLVER',
deployerId: 'RT_MAVEN_DEPLOYER'
)
}
}
stage ('Publish build info') {
steps {
rtPublishBuildInfo (
serverId: "ETI_ARTIFACTORY"
)
}
}
stage('Build a Docker image and push to Artifactory'){
steps {
sh 'mvn docker:build docker:push'
}
}
}
}

这是使用shell命令设置的管道,这确实有效。

pipeline {
agent any
stages {
stage('Maven exec') { 
steps {
sh 'mvn clean package deploy'
}
}
stage('Build a Docker image and push to Artifactory'){
steps {
sh 'mvn docker:build docker:push'
}
}
}
}

这个答案侧重于使用Artifactory管道API相对于直接调用maven的优势(关于401响应的另一个问题已经在这里得到了回答(。使用Artifactory管道API有三个主要优点。

  1. 并行maven部署-我们最近发表了一篇博客文章,讨论了这一优势。

  2. 安全性-使用Artifactory管道API时,您可以在Jenkins中管理凭据,而不是将它们存储在settings.xml或作为环境变量。Jenkins为您负责凭据加密和管理。

  3. 更好的控制-使用Artifactory管道API,您不再需要在settings.xmlpom.xml中管理Artifactory服务器URL和存储库。您可以从管道脚本中完全控制构建的解析和部署目标。你可以在这里阅读更多关于这方面的信息。

正如Eyal Ben Moshe所指出的,解决方案是使用"安装"目标,而不是"部署"目标。如果我仔细阅读这个例子,我会看到的。

最新更新