Re: [cross-project-issues-dev] Hudson job polling tips

[Matthias Sohn]

On Thu, Jun 12, 2014 at 7:59 PM, Thanh Ha  wrote:

> Hi Everyone,
>
> Occasionally we see Hudson jobs configured for polling which are far too
> aggressive by polling every minute. If your polling job looks like this "*
> * * * *" it is configured to poll every minute. You should instead consider
> configuring your job using the Hudson built in @hourly, @daily, etc...
> which will set up a more reasonable polling interval. However if you do
> require a smaller polling interval consider setting it to 5, 10 or 15
> minutes to give your job a chance to finish polling from the last polling
> attempt instead of polling every minute.
>
> For example:
>
> */5 * * * *   # for 5 minutes
> */10 * * * *  # for 10 minutes
> */15 * * * *  # for 15 minutes
>

The Jenkins Gerrit Trigger plugin also supports triggering builds when a
change in code review is submitted
(Gerrit event *Change Merged) *or when a ref is updated in case a change is
pushed directly without code review
(Gerrit event *Ref Updated)*. This way, if your project is using Gerrit,
you can completely get rid of polling and
instead trigger the builds through Gerrit stream events. You also gain
faster turnarounds since builds
are triggered immediately after a change reaches a branch. We are using
this feature here at SAP.

Unfortunately this feature seems not to be available (yet ?) with the
Hudson Gerrit Trigger plugin which seems
to be wildly outdated  (last release Oct 2012) compared to the Jenkins
version (last release April 2014).
I tried to use these events for JGit and EGit builds but it seems the
Hudson plugin is too old to support
this. I filed https://bugs.eclipse.org/bugs/show_bug.cgi?id=437313 to ask
the Hudson team if they could fix that.

--
Matthias
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] DLTK in Luna RC4

[Benjamin Cabé]

Adding Koneki to the thread to make sure this gets noticed – I strongly suspect 
LDT might be impacted too

Benjamin

Le 12 juin 2014 à 21:31, Wayne Beaton  a écrit :

> Greetings folks.
> 
> We noticed that DTLK updated their aggregation file only just this week to 
> point at their 5.1 bits. Too late, I'm afraid to make it into the RC4 build 
> (which currently includes their 2013 "5.0" bits) and EPP packages.
> 
> Which Luna projects consume DLTK? (PDT and who else?)
> 
> Have you been testing on DLTK 5.1?
> 
> Are you good-to-go with DTLK 5.0?
> 
> What are our options?
> 
> Wayne
> -- 
> Wayne Beaton
> Director of Open Source Projects, The Eclipse Foundation
> Learn about Eclipse Projects
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] DLTK in Luna RC4

[Wayne Beaton]

Greetings folks.

We noticed that DTLK updated their aggregation file only just this week 
to point at their 5.1 bits. Too late, I'm afraid to make it into the RC4 
build (which currently includes their 2013 "5.0" bits) and EPP packages.


Which Luna projects consume DLTK? (PDT and who else?)

Have you been testing on DLTK 5.1?

Are you good-to-go with DTLK 5.0?

What are our options?

Wayne
--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation 


Learn about Eclipse Projects 
EclipseCon France 2014 
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] The "Final Daze" for Luna

[David M Williams]

I've updated the "Final Daze" document for Luna's release. See 

https://wiki.eclipse.org/Luna/Final_Daze

For the majority of people, here's a summary of what you need to know (and 
do) between now and the release date of 6/25: 


1.  Clean up old builds on downloads and move previous releases to 
archives. 
2.  Provide data for Infocenter docs, for help.eclipse.org bug 436372. 

3.  Put your final bits in their final resting places, with their 
final names, early -- during quiet week -- but don't advertise them, and 
don't make "visible" to the world. Be sure to change, correct or add 
metadata -- such as download.php mirror URLs -- so they are correct for 
final location and names. 
4.  On official release day, Wednesday, June 25, check cross-project 
list approximately 9 AM Eastern to make sure there is no "Wait!" message. 
Once you see a "Go" message, you're free to advertise your release and 
make visible to the world. (And, while your thinking of it, just as well 
update Foundation's metadata to change "planned" to "completed", etc.) 
5.  Keep an eye open for a few hours to make sure no reports of "bad 
things happening", but otherwise Blog, Tweet, Celebrate! 


And, when I say "majority of people" typically one or two people per 
project actually need to do anything, but everyone else might just like to 
know what's going on, help test, etc. (not to mention, blog, tweet, and 
celebrate! :) 

Of course, the actual wiki document goes into much more detail, if you'd 
like to read all about it ... and, actually, for those that have not been 
through it before, it would be a good idea to read the whole wiki document 
... there's no way those 5 bullets would make sense to "new comers" but I 
hope are adequate reminders for "old timers". 

I hope you find it helpful ... and hope your "final final testing" is 
going well. 

Thanks, 


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Hudson job polling tips

[Thanh Ha]

Hi Everyone,

Occasionally we see Hudson jobs configured for polling which are far too 
aggressive by polling every minute. If your polling job looks like this 
"* * * * *" it is configured to poll every minute. You should instead 
consider configuring your job using the Hudson built in @hourly, @daily, 
etc... which will set up a more reasonable polling interval. However if 
you do require a smaller polling interval consider setting it to 5, 10 
or 15 minutes to give your job a chance to finish polling from the last 
polling attempt instead of polling every minute.


For example:

*/5 * * * *   # for 5 minutes
*/10 * * * *  # for 10 minutes
*/15 * * * *  # for 15 minutes


Another tip I wanted to mention was about using the file system instead 
of the git web URLs such as git://, ssh://, http://. The Hudson servers 
are configured with the same mount points as build.eclipse.org so you 
can actually poll from git at the file system level. For example instead 
of using:


git://git.eclipse.org/gitroot/cbi/org.eclipse.cbi.maven.plugins.git

You can simply use /gitroot/cbi/org.eclipse.cbi.maven.plugins.git as 
your git clone URL. This will cause your job to poll directly from the 
file system and not cause any additional network connection to occur and 
saving our services from the extra polling load. As an example our CBI 
project build jobs are configured to pull from the file system level 
URLs [1] (Committers at Eclipse can login and see the job configuration).


Hope this helps,


Thanh

[1] https://hudson.eclipse.org/cbi/job/cbi-maven-plugins-build/

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Luna RC4 staging repo is complete

[David M Williams]

http://download.eclipse.org/releases/staging/

As I am sure you all know, this is our final aggregation build for Luna, 
unless a blocking issue is found. 

I always like to emphasize, that, at this point, a "blocking issue" that 
would lead to a re-spin has to be more than a typical "bad problem" for a 
one project ... but more along the lines of something that "destroys all 
data in a project or workspace" or "prevents installs or updates of other 
projects from occurring" or that sort of thing. If you do find a bad bug 
that effects just  your project's function, I encourage you to a) look for 
and document "work arounds" and/or b) prepare a "project level patch" that 
you could make available by the time we release, so users can take 
advantage of it immediately after they install the release. This is purely 
for stability reasons ... that is, it is often better to "ship" with a 
known bad bug, than to risk fixing one bug and exposing something even 
worse (which would be hard to find in time, since by then little time left 
for testing). And just so I don't seem negative ALL the time ... if you 
sincerely believe you found a bug that really would be bad for the 
reputation of Eclipse as a whole, or something, discuss with your project 
and PMC and other Eclipse leaders and if they all believe it worth 
mentioning here on cross-project list, then please do. Even if the answer 
is "no, no re-build", it doesn't hurt to keep everyone informed. 

Also important for you to know, this "staging" repo is NOT moved to 
.../releases/luna on Friday, like we normally do, since that is Friday the 
13th [JUST KIDDING!]. The real reason it just stays on staging is that 
would essentially be "pre-releasing" the whole train. Instead we always 
have a "quiet week" for final preparations, final adopter testing and 
builds, etc., and then formally release it (make visible) on the long 
scheduled date of Wednesday, June 25th. 

I will be sending out a "what to do during quiet week" note in the next 
day or two (some version of "Kepler Final Daze" document, updated for 
Luna). 

Let us know if questions or issues, by posting here to this cross-project 
list. 

And my personal thanks for those final pushes for improvements in "repo 
reports" -- no missing "about" files, good improvements in unsigned 
bundles, and some improvement in making feature licenses (SUA's) current. 
We'll continue to work towards perfection for SR1 and Mars! 

Much thanks to you all, 

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev