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

VERIFIED FIXED in Q3 11 - Serrano

Status

Tamarin
Build Config
P1
normal
VERIFIED FIXED
8 years ago
8 years ago

People

(Reporter: Edwin Smith, Assigned: Brent Baker)

Tracking

unspecified
Q3 11 - Serrano
Bug Flags:
flashplayer-qrb +

Details

Attachments

(4 attachments, 1 obsolete attachment)

Comment hidden (empty)

Updated

8 years ago
Assignee: nobody → cpeyer
Status: NEW → ASSIGNED
Flags: flashplayer-qrb+
Target Milestone: --- → flash10.2
(Reporter)

Comment 1

8 years ago
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
Priority: -- → P1

Comment 2

8 years ago
Please fix asap.
Assignee: cpeyer → brbaker
(Assignee)

Comment 3

8 years ago
Created attachment 480100 [details] [diff] [review]
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
Attachment #480100 - Flags: review?(cpeyer)
(Assignee)

Comment 4

8 years ago
Created attachment 480108 [details] [diff] [review]
v2. silence the sandbox if repo is not from hg.mozilla.org

silence all sandbox builds that are NOT from hg.mozilla.org
Attachment #480100 - Attachment is obsolete: true
Attachment #480108 - Flags: review?(cpeyer)
Attachment #480100 - Flags: review?(cpeyer)

Updated

8 years ago
Attachment #480108 - Flags: review?(cpeyer) → review+
(Assignee)

Comment 5

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

Patch pushed as 5305:9528164a7cfc
(Assignee)

Updated

8 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
(Assignee)

Comment 6

8 years ago
Created attachment 480611 [details] [diff] [review]
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.
Attachment #480611 - Flags: review?(fklockii)
Comment on attachment 480611 [details] [diff] [review]
fix cURL alignment failures in sandbox

R+ubber stamp.
Attachment #480611 - Flags: review?(fklockii) → review+
(Assignee)

Comment 8

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

patch pushed as 5306:1a1f6788ac4c
(Assignee)

Updated

8 years ago
Status: RESOLVED → VERIFIED
(Assignee)

Comment 9

8 years ago
Created attachment 480652 [details] [diff] [review]
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
Attachment #480652 - Flags: review?(cpeyer)

Updated

8 years ago
Attachment #480652 - Flags: review?(cpeyer) → review+
(Assignee)

Comment 10

8 years ago
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.
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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 12

8 years ago
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
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago8 years ago
Resolution: --- → FIXED
(Assignee)

Comment 13

8 years ago
Actually there are a couple more files that are still hiding the output. Will get a patch together.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 14

8 years ago
Created attachment 480944 [details] [diff] [review]
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
Attachment #480944 - Flags: review?(cpeyer)

Updated

8 years ago
Attachment #480944 - Flags: review?(cpeyer) → review+
I just tried again, seems to be working.  Thanks!
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago8 years ago
Resolution: --- → FIXED
(Assignee)

Comment 16

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

patch pushed as 5323:a837d40687b9
(Assignee)

Updated

8 years ago
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.