573509 - build logfiles are not uniquely named when running in the sandbox

Status: VERIFIED WONTFIX

(Tamarin Graveyard :: Build Config, defect, P2)

Description

[Brent Baker]

When running in the sandbox, most of the output from running the step is captured and uploaded to the server for later browsing. This currently works fine for 99% of the buildsteps as the logfile names can be made unique based on the buildstep.

- acceptance, compile
- shell name
- vmargs used

so you end up with:
- acceptance-avmshell.log
- acceptance-avmshell-Dinterp.log
- acceptnace-avmshell_wordcode.log
etc.

This is fine for all of the builders where there is only one slave that does the work, however there are some platforms that are split between a couple of buildslaves because they are slow. This causes a problem when we track running the smokes because the current logfile name is smokes-{slavename}.log. The slavename is really the /platform/ which is not unique when there are multiple slaves running a platform (like mac-ppc, linux-arm). This will cause the logfile to be overwritten when uploaded to the server.

Comment 1

[Brent Baker]

I had initially thought that this would be easy since there is a ${slavename}
variable available in the scripts, but this is NOT unique and is actually just
the "platform". 

I think the /best/ solution would be to pass/expose the actual buildername from
buildbot to the scripts. This would probably be done by passing the buildername
via WithProperties('buildername', name), then in the scripts there will be an
env variable that will match exactly with the buildername (ex: linux-arm,
linux-arm2)

Other hack/simple option would be to append a timestamp to the log name. This
would probably ensure uniqueness for our scenario but would make it more
difficult to know which log file came from which slave (was it from linux-arm
or linux-arm2). This would ONLY be an issue if you were looking at the log
files only on the server, if you followed the URLs via buildbot it would be ok
since they would link to the proper file.

Comment 2

[Trevor Baker]

Is this still an issue?

Comment 3

[James Sudduth]

After the changes we made recently, removing some of the problem platforms and moving things around, I'm not sure. I'll review the slave set up to find out.

Comment 4

[James Sudduth]

We aren't splitting builds between slaves anymore in the sandbox so it seems like this work isn't needed, at least right away. Is it worth doing this now in case we decide some time in the future to split builds among slaves again?

Comment 5

[Brent Baker]

I vote that this is resolved as WONTFIX, we are moving completely away from having multiple platform slaves and instead have a single controlling slave which can distribute the workload.