Re: How does "Build whenever a SNAPSHOT dependency is built" work?
On Tuesday, April 16, 2019 at 12:24:20 AM UTC+2, Cyrille Le Clerc wrote: > > Hello Aaron, > > If all your downstream branches have a dependency on the same upstream > snapshot version, then yes, all downstream pipelines will be triggered, we > don't differentiate on the branch identifier. > Thanks. I completely missed this answer :-) > > Did you expect a different behaviour? Wouldn't all the branches of the > downstream job deserve to be triggered? > I try to build a system where we can build PRs across projects. In each project, the PR will use the same branch name. My reasoning is: There will be code changes which will break other branches (removed or new API). Most of our products use at least three projects: Utils, Core and Client. A lot of code is built only in Core and Client but sometimes, we need code in Utils for a client feature. During one release cycle, all three projects will use a SNAPSHOT version. That way, a developer can finish the whole feature in a single JIRA issue (and three PRs in git). The single feature can be reviews as one and then merged in quick succession, causing builds of the master branch in three jobs. Some people here argue that it's easier to just create a release of Utils, then a release of Core and then Client but if it turns out the Utils code has a bug, you have to release everything again. I'm not a fan of 7 releases / day. It puts a lot of stress on the Maven Repo since it can't distinguish between "important" and "oh well" releases. Regards, Aaron Digulla > > > On Wednesday, April 10, 2019 at 1:15:26 PM UTC+2, Aaron Digulla wrote: >> >> Hello, >> >> Is there documentation how this feature works? >> >> I'm especially interested how it behaves when jobA builds a branch X for >> project A and project B has a dependency on A. Both A and B are >> multi-branch pipeline projects. >> >> Will that trigger a build of branch X of B or "build all branches of B"? >> >> Regards, >> >> Aaron Digulla >> > -- 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 jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/58dd4a55-9671-4a28-8344-3bf16df58ef3%40googlegroups.com.
Re: jenkins slave on docker does not see "sh" command
On Thursday, April 11, 2019 at 5:18:55 PM UTC+2, Polak wrote: When I run it on jenkins slave (docker image) I have an error: > > sh: 1: /var/lib/jenkins/bin/login-bash: not found > > > On master Jenkins (installed on physical machine not on docker) it works > properly. > > Ceck the "login shell" for the user that runs the Jenkins slave. It should be /bin/bash but seems to be just "login-bash" (without an absolute path) in your case. Regards, -- Aaron Digulla -- 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 jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/0681f438-33d8-40b9-bba2-fa612a1d8bd2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Unit tests for Scripted Pipeline
On Sunday, April 7, 2019 at 10:10:07 PM UTC+2, Sverre Moe wrote: Is it possible to create unit tests for our scripted pipeline? > > How can certain sections of the pipeline be mocked, like fetching from > Git, tagging to Git, Uploading to Nexus? > > Anyone been able to fully unit test scripted pipeline? > > I found this project at GitHub regarding Unit testing pipelines. > https://github.com/jenkinsci/JenkinsPipelineUnit > I'm using this right now and it works well. Out of the box, several commands are not mocked (build, withMaven, etc) but it's simple to do so (usually just one line). withMaven() is a bit more complex to write to make sure the bindings are correct. See https://github.com/jenkinsci/JenkinsPipelineUnit/issues/140 Regards, -- Aaron Digulla -- 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 jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/30c1a1f3-43a6-47fe-9bdb-b639954d4130%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Calling java static methods from groovy dsl
This is strange. My first guess would be that the class isn't on the
classpath of the script but then, the import should fail as well.
Is there a reason why you omitted the import in the code sample you pasted?
Does it work when you call it before the try{}?
Can you call other methods of the class?
> I am importing class as import com.jda.JenkinsUtil and using it in script
> file pipeline.groovy as below .
> I am always facing issue as
>
> groovy.lang.MissingPropertyException: No such property: JenkinsUtil for class
>
>
--
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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/4c017970-8129-416e-852a-47504541bdb2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Send mail to mailbox when there's an infrastructure fail
Hi Sarfroz, To make sure I understand you correctly: - Your Git server was down - Jenkins did start a job - The job tried to check out the code from Git - That step failed - You didn't receive a mail for this specific failure (usually, it works) - You're using Scripted Pipeline, not Declarative Pipeline Correct? The problem here is that the mail recipients come from the Jenkinsfile. When Git isn't running, Jenkins can't get the Jenkinsfile and therefore has no chance to figure out where to send mails. Try to set up monitoring of the Git server outside of Jenkins. Alternatively, use a freestyle Job triggered by cron which periodically checks that it can connect to the Git server (just execute a git ls or something again a small repo). You can then send a mail from this job when it fails. Regards, Aaron Digulla -- 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 jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/fd687f45-86ee-4530-b54f-fe1d4465a2cb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Opinions about aggressive reuse strategy for Jenkins pipelines
Hi David I'm describing all of this for background. What I'm asking the community > is, is this a reasonable strategy? I can't help the feeling that this is > taking reusability a bit too far. I can't give any technical arguments > against it, so I'm just looking for some perspective. > I think this is a sound strategy. Without this, projects will quickly become snowflakes. Every team will start to invent their own solution for similar problems. Many of those will be haphazard because people don't have time and/or knowledge to understand the underlying issue and correctly fix many problems. So the solutions tend to be brittle and there will be a lot of conversations: "Jenkins sucks. It always breaks" "What happened?" "Well ... [long explanation]" "Hey, we had that too. We just [...]" "Oh." Regards, Aaron Digulla -- 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 jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/9c086c8c-587b-43dd-9da0-5e2d6ee4319d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
How does "Build whenever a SNAPSHOT dependency is built" work?
Hello, Is there documentation how this feature works? I'm especially interested how it behaves when jobA builds a branch X for project A and project B has a dependency on A. Both A and B are multi-branch pipeline projects. Will that trigger a build of branch X of B or "build all branches of B"? Regards, Aaron Digulla -- 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 jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/77b48911-4338-452f-a759-9058d3864902%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: "[Multijob] - [ERROR] - Problems occurs on injecting env. vars as a build step: Java heap space", does anyone know, what we can do about it?
On Friday, March 29, 2019 at 2:29:35 PM UTC+1, Nico van de Kamp wrote: I see now this error "[Multijob] - [ERROR] - Problems occurs on injecting > env. vars as a build step: Java heap space" and I've been searching on the > internet but till now, I do not find a solution to resolve this issue? Also > the other team members have searching for a solution. I know what the heap > means for Java. > > What my colleague already have done is: > >- Jenkins.xml: Xrs -Xms8192M Xrs -Xmx8192M -Xss64M >-XX:MaxPermSize=512M -jar "%BASE%\slave.jar" -jnlpUrl http://... >-secret xxx > > Note: MaxPermSize is unrelated to the problem and not used with Java 8 anymore. In fact, you should see a warning in the logs: https://stackoverflow.com/questions/18339707/permgen-elimination-in-jdk-8 -Xms8192M allocates 8 GB of memory right from the start. This can help with performance. At least, it makes sure that the OS can allocate this much memory before it starts the slave. This eliminates one OOM candidate where you've configured Java for enough memory but the OS simply doesn't have it. -Xmx8192M should fix your problem unless 1. it's not used. Look at the process table of the slave when the job is running to make sure the option was picked up (it should be but checking is better than believing). 2. you have a huge memory leak. If it always stops at this point, then check the environment variables. Maybe someone was "clever" and tried to put a huge amount of data into an environment variable. >- Searching the internet to find if someone else has also this problem > > This doesn't work because every memory leak is different. You will have to understand your own code, how your configured Jenkins and how everything works. Use a memory profiler like YourKit or or try to disable things until the error goes away. Regards, Aaron Digulla -- 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 jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/e72fb5b4-5346-497a-838a-a5c962208da0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Wrong output on .../job/*/maven
On Thursday, March 21, 2019 at 4:20:54 PM UTC+1, Cyrille Le Clerc wrote: > > > >> Please see new FAQ entry > https://wiki.jenkins.io/display/JENKINS/Pipeline+Maven+Plugin#PipelineMavenPlugin-HowcanItroubleshootproblemsoftriggerofdownstreampipelines > > I have improved the FAQ entry based on your feedback, can you please have > a look? > Much better. Only the last sentence looks cut off: "Troubleshooting details are added". Did you mean "You will find details to troubleshoot the issue below that line"? > > > I had to add a "Pipeline Graph Publisher" with the dropdown "Add > Publisher Options". In there, I could switch the option "Maven lifecycle > phase threshold" from "deploy" to "install". > > Good that you figured this out. The User Experience is not great but I > didn't find better so far. > How about printing "downstream not triggered because project used "mvn install" and the lower limit for triggering is "mvn deploy" + link to config where you can change that or a help page? > > > That leaves the weird behavior of the artifactsPublisher and my comments > about the new FAQ item. > > There is a non intuitive UX on the Pipeline Maven Plugin here: the > artifactPublisher is just about "fingerprinting" and "archiving" the > generated artifacts, it is NOT about updating the dependency graph that > tracks (in a database) the produced and consumed artifacts. The > "pipelineGraphPublisher" was introduced way after the "artifactsPublisher" > (~6/12 months after). > I suspect that the "pipelineGraphPublisher" is invoked twice in your > pipeline. > I searched for "pipelineGraphPublisher" which got me no hits. Then "graph" which produces exactly one hit: [withMaven] Publishers: Pipeline Graph Publisher: 12 ms, Generated Artifacts Publisher: 31 ms, Junit Publisher: 52 ms, Dependencies Fingerprint Publisher: 4 ms, Jacoco Publisher: 12 ms, Open Task Scanner Publisher: 14 ms Seems like that plugin is a quiet one :-) Any hints? > That triggers the downstream builds of feature branches. Now, I have to > figure out how to share the artifacts. See my post "Chained builds" for my > thoughts on that. > > I'll have a look, it is a difficult problem to solve. I didn't yet deep > dive in https://maven.apache.org/maven-ci-friendly.html that seem to be > related to the problem you want to solve. > I read through the document and it seems an attempt to solve something but after reading it, I'm unsure what exactly. Maybe what they try is to give the build result of each branch a unique version? So you could deploy all of them to Nexus and the next build would pick the right one to use. The use of the Flatten Maven Plugin worries me a bit but I think this is necessary because Maven doesn't support variables in the project.version property (for good reason). But some things like removing dependencyManagement elements seems completely wrong to me. Still, the idea to solve the "Maven doesn't support branches" by using one version per branch sounds promising. Does Jenkins take the version into account when building downstream projects i.e. if the downstream project has a dependency on 2.x-SNAPSHOT, it will not get triggered when I build 2.x-FOO-SNAPSHOT? Regards, -- Aaron Digulla -- 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 jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/37b50674-93ec-4c46-b852-2ef6f19612a3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Why does my Jenkins not run a .exe file?
Hi Balu, This is very weird. Some things that you can try: - Run another exe (something simple). Does that work? - Does it work when you put "cmd /c" in front of the name of the executable? - Do you get an error when you add a typo to the name of the executable (maybe Jenkins can't find it)? - Does the program wait for input on stdin? Try to close stdin (not sure how do that on windows, on Linux, it would be "< /dev/null") - Does the master get stuck (i.e. the web interface doesn't respond anymore) or the slave? Regards, -- Aaron Digulla -- 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 jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/b5f803e6-754a-4faa-ad25-e8fab1e2aa7d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Trigger from GIT to Jenkins buildWithParameters ignores parameter value in pipeline
Use params.ABC "params" contains build parameters, "env" the environment. -- Aaron Digulla -- 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 jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/e24195ee-68a7-44f9-a714-81170d98cb8f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: sending email for unstable builds
Hi,
I'm using this code:
node(...) {
try {
...add stages here...
} catch(Exception e) {
currentBuild.result = 'FAILURE' // Let the post step know that
the build failed with an error.
throw e
} finally {
builder.post(currentBuild)
}
} // node
The code for post() looks like so:
def post(def currentBuild) {
String currentResult = currentBuild.result ?: 'SUCCESS'
echo "post ${currentResult}"
try {
postAlways(currentBuild)
} catch(Exception e) {
def converted = toString(e)
echo "postAlways failed (ignored):\n${converted}"
}
if (currentResult == 'SUCCESS') {
success(currentBuild)
} else {
failed(currentBuild, currentResult)
}
}
Hope this helps,
Aaron Digulla
On Thursday, February 28, 2019 at 9:41:50 PM UTC+1, Faad Sayaou wrote:
>
> Hi everyone
> I am using the extended email plugin for notification when the build fails
> by using try catch. I will also like to send email when the build is
> unstable.
>
--
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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/eda1618f-94e8-4efa-9875-3d48e715a34f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Wrong output on .../job/*/maven
Hi Cyrille, I could fix one of my problems in the mean time: To get the downstream build working, I had to do the following: In "Manage Jenkins" / "Global Tool Configuration", I had to add a "Pipeline Graph Publisher" with the dropdown "Add Publisher Options". In there, I could switch the option "Maven lifecycle phase threshold" from "deploy" to "install". That triggers the downstream builds of feature branches. Now, I have to figure out how to share the artifacts. See my post "Chained builds" for my thoughts on that. That leaves the weird behavior of the artifactsPublisher and my comments about the new FAQ item. Thanks a lot, Aaron Digulla -- 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 jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/9db5832a-3bb0-448d-8708-b7c74d67fb64%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Wrong output on .../job/*/maven
Hi Cyrille,
Thanks for the quick answer. My first reply somehow got swallowed.
Hi Aaron,
>
> - Why do I sometimes get duplicate artifacts? They are not duplicated on
>> disk. In the console log, I just see a single invocation of
>> artifactsPublisher but sometimes, it reports the same artifact several
>> times.
>
>
> Can you share the Jenkinsfile and the logs of your build? Usually artifact
> are displayed several time because "mvn package" or more than "package"
> ("install" or "deploy") is called several times in the build (e.g.
> invoking "mvn test" then "mvn deploy")
>
I checked the console log. In both builds, I see Maven started twice with
these options:
1.
mvn --batch-mode --show-version -U clean install sonar:sonar -P coverage
-Dmaven.repo.local=...
2.
mvn --batch-mode --show-version -U license:add-third-party
license:third-party-report site -Dmaven.repo.local=...
The artifactsPublisher is invoked for #1, in #2, I'm disabling all publishers
with "publisherStrategy: EXPLICIT". In the log, artifactsPublisher appears in
the "build" step (#1) and not in the "license check" step (#2).
I really can't see why it gets additional artifacts in build of project A but
not B. Jenkinsfile and Pipeline library are the same for both projects, so I'd
expect the same output. The good news is that it's stable. It always archived
twice in A and never in B.
>
>
>> - Why isn't C listed as "Downstream Job" of B?
>
>
> Can you please share screenshots of the "/maven" tab of both job "B" and
> "C"?
>
C looks like this:
-
[...]
*Artifacts generated by this build. Hyperlink added when the artifact has
been deployed to a Maven repository. *
*Upstream Builds*
* Builds that generate artifacts that are dependencies of this build. This
list is filtered by permissions, you must have the ITEM.Read permission on
the job to see it. Note that these builds have not necessarily triggered
this job: a trigger "Build whenever a SNAPSHOT dependency is built" must be
configured on this job. *
*Downstream Jobs*
* Jobs that have dependencies on artifacts generated by this build. This
list is filtered by permissions, you must have the ITEM.Read permission on
the job to see it. Note that these jobs will not necessarily be triggered
by this job: a trigger "Build whenever a SNAPSHOT dependency is built" must
be configured on the downstream job. *
*Dependencies*
*Dependencies recorded according to the settings of the "Pipeline Graph
Publisher" By default, only "snapshot" dependencies are recorded and
"release" dependencies are ignored to optimize the size on disk of the
database of the "Pipeline Maven Plugin". *
-
B looks the same, only that it lists "C" under "Dependencies" but not in
"Upstream Builds".
By default, downstream pipeline triggers only work when a pipeline
> is"success" or "unstable" and when the "mvn" goal is "deploy". This means
> that by default, "mvn package" or "mvn install" would not trigger a
> downstram pipeline.
>
That would be it. I avoid to publish to Nexus (see my post "Chained builds"
for the reasons). Is there a way to activate this for "mvn install"?
>
>
>> - How can I collect more information to debug this?
>
>
> Please see new FAQ entry
> https://wiki.jenkins.io/display/JENKINS/Pipeline+Maven+Plugin#PipelineMavenPlugin-HowcanItroubleshootproblemsoftriggerofdownstreampipelines
>
Can you please add a link to
https://wiki.jenkins.io/display/JENKINS/Logging to the FAQ item?
And I really don't understand the last point in the list.
> Look at the pipeline build logs, troubleshooting details are added
This sounds as if there is already a log file for pipeline builds. Do you
refer to the console log? Would enabling the two loggers add more output to
the console log? Or is that written elsewhere? What is the file name? Which
folder?
Is looking really enough? Don't you have to start the build before that?
And "are added" is confusing. Did you mean "will be added there"?
> On Monday, March 18, 2019 at 3:15:26 PM UTC, Aaron Digulla wrote:
>>
>> I have three projects in my example, A, B and C.
>>
>> A is built on another Jenkins PROD. It's deployed to Nexus.
>>
>> B depends on A. It's built on Jenkins TEST.
>>
>> C depends on B. It's also built on Jenkins TEST.
>>
>> All three projects have a SNAPSHOT version.
>>
>> The web page .../job/*/maven of B show
Chained builds
e massive disk usage. Even for simple projects, Maven downloads 100-200 MB of code for its plugins. So 100 repos would need 10 TB of disk space (10 projects with 10 feature branches). It's also somewhat slow but in my tests, copying 200 MB of Maven repo took < 10s, so it's bearable. Also, I'm not sure how to solve "fragmented" chains when there is a feature branch for A and C but not for B. In this case, the build of C needs to trigger just A, skipping B. A may depend on the SNAPSHOT version of B from the master branch. Any comments? Has someone already set up something like this? Does this work reliably? How can I solve the disk space issue? Regards, -- Aaron Digulla -- 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 jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/ed355d9b-5d54-4d23-8c57-e9c7581acc2a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Wrong output on .../job/*/maven
I have three projects in my example, A, B and C. A is built on another Jenkins PROD. It's deployed to Nexus. B depends on A. It's built on Jenkins TEST. C depends on B. It's also built on Jenkins TEST. All three projects have a SNAPSHOT version. The web page .../job/*/maven of B shows me: - All artifacts of B twice (*.jar, *.jar, *-sources.jar, *-sources.jar, *-test-sources.jar, *-test-sources.jar, *.pom, *.pom, *-tests.jar, *-tests.jar) - No "Upstream Builds" - No "Downstream Jobs" - A is listed as dependency I'd expect each artifact of B once and C as downstream job. Not sure about dependencies but seeing A here would be nice even though it's built on another Jenkins. The web page .../job/*/maven of C shows me: - Just some duplicate artifacts. This is a multi-module build. I'm seeing the root POM twice, everything else just once. - No "Upstream Builds" - No "Downstream Jobs" - A and B are listed as dependencies. As far as I can tell, the two jobs use the same Jenkins Pipeline. They are both of type "Multibranch Pipeline". B gets deployed to Nexus when I build the "master" and release branches but not for feature branches. C only gets deployed to Nexus when it's a release branch. I'm admin on Jenkins TEST, so I'm pretty sure it's not a ITEM.Read permission issue. There is no config option "Build whenever a SNAPSHOT dependency is built" for the jobs B or C. I can see the option when I click "View Configuration" in .../job/*/master/configure Questions: - Why do I sometimes get duplicate artifacts? They are not duplicated on disk. In the console log, I just see a single invocation of artifactsPublisher but sometimes, it reports the same artifact several times. - Why isn't C listed as "Downstream Job" of B? - How can I collect more information to debug this? Regards, -- Aaron Digulla -- 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 jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/784f85d4-32f0-422c-8337-477dc36e8cc0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: How can we achieve the same effect as Jenkins 1's "Deploy artifacts to Maven repository" with Jenkins 2's pipelines?
Hi Cyrille, My main goal is prevent partial uploads in release builds since that could cause a lot of manual effort to clean up in Nexus. I'm not that concerned with partial snapshot uploads since we try to avoid them (we work a lot with branches). But being able to run some additional tests before the upload phase would be nice, too (for example, to verify that some resources are in the right place in a WAR; that has bugged us in the past and it would be nice to check with an error message explaining how to fix it). The last goal would be chained multi-branch builds. Imagine you want to build Maven and then a Maven plugin. For the plugin, you need a new feature in Maven. So you create two branches with the same name in two projects. During the build, you want the plugin job to see a Maven repo (local or remote) which contains the branch of the Maven build - but no one else! A step which allows to deploy artifacts to Nexus would be the basis for this work. Regards, A. Digulla On Friday, January 18, 2019 at 11:54:17 AM UTC+1, Cyrille Le Clerc wrote: > > Hello Aaron, thanks David > > As David said, the "Deploy artifacts to Maven repository" feature of the > Maven Job type does not exist "as is" in the Pipeline Maven integration. > > The recommended solution is to use the "-DdeployAtEnd=true" feature of > Maven. See > https://maven.apache.org/plugins/maven-deploy-plugin/deploy-mojo.html#deployAtEnd > > . > > Can you please describe more your need. Is it one of > >- Prevent partial upload of maven artifacts when a multi module >project fails >- Introduce intermediate build steps between the completion of "mvn >verify" and the upload of the artifacts (the "deploy" part of the maven >build) >- Have retires if the artifact repository is unvailable >- Other > > Cyrille > > > > > On Thursday, January 17, 2019 at 6:23:40 PM UTC+1, David Karlsen wrote: >> >> I use the option deployAtEnd in the maven plugin to achieve this >> >> Den tor. 17. jan. 2019, 16:59 skrev Cyrille Le Clerc < >> clec...@cloudbees.com>: >> >>> Hello AAron, >>> >>> This capability is niot av >>> >>> On Wednesday, January 16, 2019 at 5:16:22 PM UTC+1, Aaron Digulla wrote: >>>> >>>> Hello, >>>> >>>> For releases, I'd like to build and test all Maven modules and after >>>> the build, deploy everything at once (otherwise, someone has to waste time >>>> to clean up the mess in Nexus). >>>> >>>> In Jenkins 1, this was simple: Build with "mvn clean install" and add a >>>> post-build job "Deploy artifacts to Maven repository". >>>> >>>> Jenkins 2 still maintains a list of all artifacts which need to be >>>> deployed but I couldn't find the out how to recreate the old post-build >>>> job. >>>> >>>> How do I do that? >>>> >>>> Regards, >>>> >>> -- >>> 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 jenkinsci-use...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/jenkinsci-users/8813b207-d8f5-4718-9401-a130b475899b%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/jenkinsci-users/8813b207-d8f5-4718-9401-a130b475899b%40googlegroups.com?utm_medium=email_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- 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 jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/b8e5731b-3549-465f-a177-252f6c4fe6a5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
How can we achieve the same effect as Jenkins 1's "Deploy artifacts to Maven repository" with Jenkins 2's pipelines?
Hello, For releases, I'd like to build and test all Maven modules and after the build, deploy everything at once (otherwise, someone has to waste time to clean up the mess in Nexus). In Jenkins 1, this was simple: Build with "mvn clean install" and add a post-build job "Deploy artifacts to Maven repository". Jenkins 2 still maintains a list of all artifacts which need to be deployed but I couldn't find the out how to recreate the old post-build job. How do I do that? Regards, -- 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 jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/05ef490c-7cdc-434a-814b-f0cde7c7fe4b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
