Hello!

The Jenkins library revision can be specified in the Jenkinsfile. For exemple, 
we can use a specific version of ‘my-shared-library’ with  tag 1.0 by putting 
the following line at the beginning of the Jenkinsfile:


@Library('my-shared-library@1.0') _


Regards,
Amine TAYEB CHERIF

Le 12 mai 2019 à 08:02, Adrien Lecharpentier 
<adrien.lecharpent...@gmail.com<mailto:adrien.lecharpent...@gmail.com>> a écrit 
:

You can update the librairies as much as you want, without the need to
restart the instance. The shared libraries are cloned when the build
starts.

The fear I had during the hackergarten is more about the scope of the
change. Because the shared library is implicitly loaded, it means we cannot
specify a revision to use on one particular job. So, to test the library in
a real life environment, the changes etc needs to hit the master branche.
But as soon as this is happening, all jobs we be using it. Which means, if
what we have done has the smallest issue, it can take tremendous
proportions..

Le dim. 12 mai 2019 à 07:56, Hervé BOUTEMY 
<herve.bout...@free.fr<mailto:herve.bout...@free.fr>> a écrit :

notice 2:
one issue we had when working on such not so trivial Jenkins library
updates
is: how to test locally before updating the production server,
particularly
when the lib is shared then updates cannot be done without server restart?

this one probably deserves some explanations/documentation on our site,
since
we have ITs for every single Maven component/plugin but nothing about this
Jenkins library

Le samedi 11 mai 2019, 22:31:48 CEST Hervé BOUTEMY a écrit :
during latest Hackergarten in Paris [1], I had the chance to have Adrien
Lecharpentier [2] with me, then I gave him my ideal: - deploy only from
master = summary of previous discussions
- don't deploy until full ITs have been run on every platform, to avoid
deploying broken artifacts - let for later the discussion about which
build
to deploy (which JDK/OS build)...

then we started to work on an implementation based on local staging [3]
during build, then wagon:merge-maven-repos once every IT on every
platform
is ok

AFAIK, the implementation is not complete, I hope we'll finish during the
next session [4]

Really, it's about doing little steps together: I hope such Hackergarten
event can happen in many places, to have people work together more
efficiently than discussing in ML, which is frustrating when it remains
at
discussion status

Regards,

Hervé

[1] https://www.meetup.com/fr-FR/Paris-Hackergarten/events/tvdrwpyzgbnc/

[2] https://github.com/alecharp

[3]

https://maven.apache.org/plugins-archives/maven-deploy-plugin-LATEST/exampl
es/deploy-network-issues.html

[4] https://www.meetup.com/fr-FR/Paris-Hackergarten/events/tvdrwpyzhblc/

Le samedi 11 mai 2019, 15:07:25 CEST Mickael Istria a écrit :
Ok, thanks I'll try that.
But I'm still not really understanding what prevents Maven from calling
'mvn deploy' on that job to push snapshots to apache Maven repo.
Anything
one can help with??

On Saturday, May 11, 2019, Sylwester Lachiewicz 
<slachiew...@gmail.com<mailto:slachiew...@gmail.com>


wrote:
Hi Mickael,
i think You can try download latest snapshot dist from our Jenkins
build
from master branch [1]

Sylwek

[1]
https://builds.apache.org/view/M-R/view/Maven/job/maven-> > >
box/job/maven/job/master/lastSuccessfulBuild/artifact/
org/apache/maven/apache-maven

czw., 9 maj 2019 o 14:55 Mickael Istria 
<mist...@redhat.com<mailto:mist...@redhat.com>>
napisał(a):
Hi all,

I'd like to set up for Tycho an automated build that runs it's
master
against latest Maven snapshots, so we could more immediately spot
incompatibility like MNG-6642.
This should be quite easy to set up as a CI job.
However, what URL can I use to get access to the current snapshot
of

Maven

delivery?

Thanks in advance,
--
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>

---------------------------------------------------------------------
To unsubscribe, e-mail: 
dev-unsubscr...@maven.apache.org<mailto:dev-unsubscr...@maven.apache.org>
For additional commands, e-mail: 
dev-h...@maven.apache.org<mailto:dev-h...@maven.apache.org>





Reply via email to