How are they used in aggregation ? For other things than just info
to
add to the aggregation ?
Not used in aggregation. Purely for archiving of information (knowing
what went into the build w/o having to crack open 17 plugin jars).
>> The build logs are also mostly for investigative purposes and
if these
>> were actually available within a build that would useful (removes need
>> to wait for jenkins to load)
> Hypothetical "would" isn't enough here. For investigation, I find it
> pretty acceptable and consistent with the possible failures to either
> look at Jenkins log directly or re-run the build locally.
Not everyone has access to Jenkins.
And those who do have access sometimes find it HELLA slow. Therefore
stashing a copy of the build log on
dl.jb.org is IMHO still useful.
Rerunning builds isn't possible if the jobs actually changed
since then.
Editing for clarity, do you mean if the [job config has] actually
changed since [the last run of the job] ?
In that case you can look in the first few lines of the build log to see
the exact syntax used to invoke maven and bash.
>> What is missing is actually being able to find and read this
info.
> Can you please elaborate on an *actual* use-case which drives you to
> this assumption?
That these actually never are used and you have to know how to find them.
At the risk of getting snarky, the logs folder has been in place for
over 3 years, under every build folder created by Jenkins & our
publish.sh script. If you still can't find it, you're using the wrong
internet.
http://download.jboss.org/jbosstools/builds/stable/3.2.2.Final/2011-11-14...
>> i.e.
>>
http://download.jboss.org/jbosstools/builds/staging/jbosstools-4.2.1.CR1-...
>> doesn't actually list the zip name the md5sum relate to...also it looks
>> like the numbers are always the same which smells like a bug.
> I agree on the smell of a bug there.
This might be a consequence of the file renaming we did for 4.2 (to
support proper
jboss.org conventions), or some other refactoring (eg.,
to use git SHAs from the Source-Ref in MANIFEST.MF files).
Here's what it looks like for 4.1.2:
http://download.jboss.org/jbosstools/builds/stable/4.1.2.Final.core/2014-...
What is the maintaence effort here ? Afaik it's copy of the
files
generated in the build ?
As proven by the fact that the md5sums.txt file no longer provides
useful info, clearly there's a maintenance requirement - either we make
sure it works, or it breaks. Or we stop producing it as it's no longer
useful / needed.
So it's not about copying files, it's about deciding WHAT files to
generate. (Like every year when I ask if we still need to produce the
hibernatetools update site, or if we can trash that and just tell people
to use the Eclipse Marketplace instead. Every year I'm told the
statistics say we need to keep it.)
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com