Community
Participate
Working Groups
We are in the process to deprecate the current Hudson shared instance at Eclipse (see bug 412933 for details). You have the following jobs on this instance: * https://hudson.eclipse.org/hudson/job/jetty-rt-bundles-7/ * https://hudson.eclipse.org/hudson/job/jetty-rt-bundles-8/ * https://hudson.eclipse.org/hudson/job/jetty-rt-bundles-9/ * https://hudson.eclipse.org/hudson/job/jetty-wtp/ We offer two migration paths for these jobs: * Use the new up to date Hudson shared instance at https://hudson.eclipse.org/shared/. It is a recent Hudson installation configured the same way as the old instance was to minimize migration work. * Use a dedicated Hudson instance for each of these projects (what we call a HIPP, Hudson Instance Per Project). This way, you can create as many jobs as you want, install all the Hudson plugins you want, etc. This is the preferred path of migration as the shared instance (old or new) will be deprecated in the mid term. See https://wiki.eclipse.org/Hudson#HIPP for more details. Whatever the path you choose, the plan is: * first to copy the job to the new instance (shared or HIPP). * make it work * deactivate the job on the old shared instance * after a while without issue and after validation from your side, remove the job from the old shared instance. What is your preferred way? Is there any preferred time when I can do the migration? Is there any useless job that could be nuked? Thanks.
Joakim, Can you help Mikael migrate our Hudson setup? Jan
I'll take a look.
So I have login access to https://hudson.eclipse.org/shared/ But *NOT* https://hudson.eclipse.org/hudson/ can't login to the second one. How do I get that fixed? (I don't want a password reset)
Can someone move those builds to a HIPP that I can access. Then I'll double check them. Once they perform ok, we can kill the old ones on /hudson/
(In reply to Joakim Erdfelt from comment #2) > I'll take a look. Thanks for your help. (In reply to Joakim Erdfelt from comment #3) > So I have login access to > > https://hudson.eclipse.org/shared/ > > But *NOT* > > https://hudson.eclipse.org/hudson/ > > can't login to the second one. > How do I get that fixed? > (I don't want a password reset) On the new shared instance, you must use your email address to log in instead of your unix account name. (In reply to Joakim Erdfelt from comment #4) > Can someone move those builds to a HIPP that I can access. > Then I'll double check them. > Once they perform ok, we can kill the old ones on /hudson/ Done. I migrated the 4 jobs to https://hudson.eclipse.org/shared/view/Jetty-RT/. You should have the same permissions as on the old shared instance. Please tell me when you think everything is ok so that I can remove the jobs on the old shared instance. Thanks.
Mikael, Our hudson jobs on the shared instance don't work. We need to have maven installed. Are you able to install that for us? thanks Jan
I just fixed your build for jetty 9. Other jobs will need similar effort, but I don't know if I can run a build without publishing something undesired. Is it ok if I run jobs without setting "jetty_release_version" and "set_pom_version"?
Hi Mikael, Thanks for that, it seems the build is ok now. (Just for the record you will need to set those fields to make the build work properly). cheers Jan
Glad to hear that. For other jobs, what value can I use for my testing?
Mikael, For jetty-8, use its most recent release version of 8.1.18.v20150929 For jetty-7, use its most recent release version of 7.6.18.v20150929 thanks for this, Jan
I managed to fix the job for jetty 7. Unfortunately, for Jetty 8 I can't build despite the configuration is very close to what is used on the old shared instance. Could you have a look at the log [1] and tell me if it makes you think about something? Thanks. [1] https://hudson.eclipse.org/shared/view/Jetty-RT/job/jetty-rt-bundles-8/lastBuild/console
Did you have the time to check the new builds?
Hi Mikael, I got the jetty-rt-bundles-8 job on the old hudson instance working, but I cannot make the job on the new shared hudson instance work. I've narrowed the problem down to the arguments that are passed to maven. The variable jetty_release_version must be passed as a -D arg to maven, which the pom.xml checks, and then sets the property jetty-release-version with the correct version of jetty. So its like that property is not being passed in correctly. Here's a comparison of the maven command line from the working old hudson job, and the same from the new hudson job: Old hudson: [jetty-rt-bundles-8] $ /shared/common/apache-maven-3.0.3/bin/mvn -DBRANCH_NAME=jetty-8 -Dset_pom_version=8.1.17.v20150415 -Djetty_release_version=8.1.17.v20150415 -Ddelete_tycho_meta=true -Dforce_context_qualifier= -Dpack_and_sign=true -Dmaven.repo.local=/tmp/jetty-builds/jetty8/localRepo -Dpack-and-sign=true -Djetty-release-version=8.1.17.v20150415 clean verify -X -U New hudson: [jetty-rt-bundles-8] $ /shared/common/apache-maven-3.0.5/bin/mvn clean verify -X -U -V -B -e -DBRANCH_NAME=jetty-8 -Dset_pom_version=8.1.18.v20150929 -Djetty_release_version=8.1.18.v20150929 -Ddelete_tycho_meta=false -Dforce_context_qualifier= -Dpack_and_sign=true -Dmaven.ext.class.path=/opt/users/genie.shared/maven/slavebundle/resources:/opt/users/genie.shared/maven/slavebundle/lib/maven3-eventspy-3.0.jar:/opt/users/genie.shared/slave.jar -Dhudson.eventspy.port=43486 -Dmaven.repo.local=/opt/users/genie.shared/workspace/jetty-rt-bundles-8/.maven/repo -f pom.xml -P pack-and-sign=true -P jetty-release-version=8.1.18.v20150929 -X -U Can you take a look at those differences? thanks Jan
My bad! I put pack-and-sign=$pack_and_sign jetty-release-version=$jetty_release_version in profile section instead of the properties one! It seems to work much better now.
Could I remove jobs from the old shared instance and close this bug now?
(In reply to Mikael Barbero from comment #15) > Could I remove jobs from the old shared instance and close this bug now? Yes please Mikael. Thank you for your help. Jan
Done. Thanks.
closing.
