I agree, jobB should not be getting the "bad" libraryA. I DO a mvn install,
but explicitly to a separate local repo. For clarity here is an
approximation of the pipeline's Jenkinsfile:
#!groovy
pipeline {
environment {
GIT_CREDENTIAL_ID = 'git_credential_name'
}
agent any
tools {
maven 'internal_maven'
jdk 'openjdk'
git 'internal_git'
}
stages {
stage('Build Parent') {
steps {
checkoutRepos([[checkoutDir: 'parent', branch: 'gold', url:
'ssh://git@fake-git-url/parent.git']], env.GIT_CREDENTIAL_ID)
withMaven(publisherStrategy: 'EXPLICIT') {
sh """
cd parent
mvn -U clean verify
"""
}
stash name: 'parent', includes: 'pom.xml'
}
}
stage('Build libraryParent') {
steps {
unstash 'parent'
checkoutRepos([[checkoutDir: 'libraryParent', branch:
'gold', url: 'ssh://git@fake-git-url/libraryParent.git']],
env.GIT_CREDENTIAL_ID)
withMaven(mavenLocalRepo: 'libraryParent/.repository',
publisherStrategy: 'EXPLICIT') {
sh """
mvn install:install-file -Dpackaging=pom
-Dfile=pom.xml -DpomFile=pom.xml
cd libraryParent
mvn clean verify -P jacoco sonar:sonar -U
-Dsonar.host.url=https://fake-sonar-url -Dsonar.scm.provider=git
"""
}
dir('libraryParent/libraryA/target/') {
stash name: 'libraryA', includes:
'libraryA-1000-SNAPSHOT.jar'
}
}
}
stage('Build appA') {
steps {
sonarAnApp 'appA'
}
}
stage('Build appB') {
steps {
sonarAnApp 'appB'
}
}
stage('Build appC') {
steps {
sonarAnApp 'appC'
}
}
}
}
def sonarAnApp(final String appName) {
unstash 'parent'
unstash 'libraryA'
checkoutRepos([[checkoutDir: appName, branch: 'gold', url:
"ssh://git@fake-git-url/${appName}.git"]], env.GIT_CREDENTIAL_ID)
withMaven(mavenLocalRepo: "$appName/.repository", publisherStrategy:
'EXPLICIT') {
sh """
mvn install:install-file -Dpackaging=pom -Dfile=pom.xml
-DpomFile=pom.xml
mvn install:install-file -Dfile=libraryA-1000-SNAPSHOT.jar
cd $appName
mvn clean verify -P jacoco sonar:sonar -U -Dsonar.host.url=
https://fake-sonar-url -Dsonar.scm.provider=git
"""
}
}
On Monday, January 21, 2019 at 8:47:56 AM UTC-7, Ricardo Torres wrote:
>
> I have an upstream component, libraryA, I build, archive, and deploy via a
> Maven job, jobA. This works great. I have a downstream Maven job, jobB,
> that has a dependency on libraryA. This also works great, except…
>
>
>
> I have a completely separate pipeline job, pipelineA specified by
> Jenkinsfile. Within that Jenkinsfile, I build a specific branch of libraryA
> I don’t want archived or deployed. In my Jenkinsfile I have
> “withMaven(mavenLocalRepo: ‘libraryA/.repository’, publisherStrategy:
> ‘EXPLICIT’)”, and inside that, “sh “””[…]mvn clean package
> sonar:sonar[…]””” (Any typos here are probably the fault of my typing here
> as I did not copy-paste. There are no errors from Jenkins when executing
> these steps.) I have also tried “options: [artifactsPublisher(disabled:
> true)]” in place of “publisherStrategy: ‘EXPLICIT’” and had the same
> results. I have verified when pipelineA builds libraryA, it does NOT get
> deployed to my remote Maven repository, and I expect it not to get deployed
> there. Good.
>
>
>
> So, what happens?
>
>
>
> Well, if I build pipelineA followed by jobB, jobB gets its copy of
> libraryA from pipelineA, causing the build to fail. If I then run jobA,
> jobB succeeds as expected.
>
>
> I could change the version of libraryA in the branch pipelineA builds, but
> I’d rather not do that as it’s not correct for my particular use case. What
> else could I do? What did I miss? (I do not admin this Jenkins instance, so
> my access is limited in that respect.)
>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/21ede97a-d08b-415c-ac7e-b9c2d77028ab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
