581664 - Tryserver logs should be publicly visible for builds submitted from hg.mozilla.org

Status: VERIFIED FIXED

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

Comment 1

[Edwin Smith]

Can we hurry up and fix this?  Here's a partial chat transcript from #nanojit last night:

<njn>	edwsmith, wmaddox: I'm using the tamarin buildbot
	<njn>	I can't get logs
	<wmaddox>	hmm.
	<njn>	it points me to some asteam URL that doesn't exist
	<njn>	any ideas?
	<wmaddox>	I know the internal build server we use at adobe was changed to do this so we didn't leak details of security-sensitive fixes
	<njn>	I've got compile errors, but without the logs I can't diagnose them
	<wmaddox>	afaik, it is the same hardware. but I can't believe we intended to break the mozilla trybot service for tamarin
	<wmaddox>	what is the URL you are being given?
	<njn>	http://tamarin-builds.mozilla.org/tamarin-redux/builders/solaris-sparc-compile-sandbox/builds/273/steps/Build_Release/logs/stdio
	<njn>	it points me to an asteam URL
	<njn>	which doesn't exist
	<wmaddox>	yes, that's an internal adobe url
	<wmaddox>	I think we have a bug, if you are seeing this url
	<wmaddox>	query Trevor about it

Comment 2

[Trevor Baker]

Please fix asap.

Comment 3

[Brent Baker]

Attachment: silence the sandbox only if repo is on asteam

Idea for how to make this work.

Only redirect io to log file if:
  1) silent==true
  2) asteam_repo=true

Now that I am thinking about this, it might be better actually check for hg.mozilla.org instead and then change the logic to:
  1) silent==true
  2) mozilla_repo==false
Probably better to always be silent if silent==true unless the repo is from mozilla, that way we do not need to remember to update this script if we change the internal hosting machine for our repos

Comment 4

[Brent Baker]

Attachment: v2. silence the sandbox if repo is not from hg.mozilla.org

silence all sandbox builds that are NOT from hg.mozilla.org

Comment 5

[Brent Baker]

Comment on attachment 480108 [details] [diff] [review]
v2. silence the sandbox if repo is not from hg.mozilla.org

Patch pushed as 5305:9528164a7cfc

Comment 6

[Brent Baker]

Attachment: fix cURL alignment failures in sandbox

Need to make sure that stderr is restored to normal and is not being redirected to the file that we are trying to upload, otherwise cURL will report an error:

curl: (18) Uploaded unaligned file size 

Since we are sending information to the file as it is being uploaded, the amount of data uploaded at the end is more than the file size at the beginning.

Comment 7

[Felix S. Klock II [:pnkfelix, :fklock]]

Comment on attachment 480611 [details] [diff] [review]
fix cURL alignment failures in sandbox

R+ubber stamp.

Comment 8

[Brent Baker]

Comment on attachment 480611 [details] [diff] [review]
fix cURL alignment failures in sandbox

patch pushed as 5306:1a1f6788ac4c

Comment 9

[Brent Baker]

Attachment: fix rev2

Builds were still silent when the repo was from mozilla.org...

Ok, my testing methodology was incorrect and this check was not working properly. I have tweaked and have double checked in a shell to make sure that this works as wanted:
>$ export repo_url=http://hg.mozilla.org/users/edwsmith_adobe.com/njmerge/
>$ if [[ "$repo_url" == http://hg.mozilla.org* ]]; then echo false; else echo true; fi
false

>$ export repo_url=http://asteam.macromedia.com/hg/users/dschaffe/tr-sandbox
>$ if [[ "$repo_url" == http://hg.mozilla.org* ]]; then echo false; else echo true; fi
true

Comment 10

[Brent Baker]

Comment on attachment 480652 [details] [diff] [review]
fix rev2

patch pushed as 5309:f84505dfc5f8

I tested a sandbox build with this change and stdio was hosted on tamarin-builds.mozilla.org instead of being copied internally to adobe's network.

Comment 11

[Nicholas Nethercote [inactive]]

Using the request form at http://tamarin-builds.mozilla.org/build_trigger/requestbuild.cfm, I requested a build of this repo:

  http://hg.mozilla.org/users/nnethercote_mozilla.com/tr-test

The links to the logs are still pointing to asteam.macromedia.com.

Comment 12

[Brent Baker]

You will need to update your TR repo to get the patches that are involved in this bug, or at least update to TR rev 5309:f84505dfc5f8

Comment 13

[Brent Baker]

Actually there are a couple more files that are still hiding the output. Will get a patch together.

Comment 14

[Brent Baker]

Attachment: fix running of acceptance

Running of the acceptance suite was still silent for all builds, now mozilla.org builds will display the acceptance output.

Tested in a sandbox build

Comment 15

[Nicholas Nethercote [inactive]]

I just tried again, seems to be working.  Thanks!

Comment 16

[Brent Baker]

Comment on attachment 480944 [details] [diff] [review]
fix running of acceptance

patch pushed as 5323:a837d40687b9