767477 - Add package tests and symbols for win8 builds

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

[Armen [:armenzg]]

Let's add such functionality as well.

Right now symbols are failing but we haven't figure out yet why.

Comment 2

[Armen [:armenzg]]

Attachment: add packaged test and symbols for win64

It might need MOZ_SYMBOLS_EXTRA_BUILDID as well.

Comment 4

[Armen [:armenzg]]

Attachment: win32-metro packaged tests

I just realized the other patch included symbols info which is not what I wanted.

Comment 5

[Armen [:armenzg]]

Attachment: add symbols for win32-metro

Do I need any appending like on armv6?

Comment 6

[Armen [:armenzg]]

Comment on attachment 640225 [details] [diff] [review]
win32-metro packaged tests

9cee0654a426

Comment 7

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 640227 [details] [diff] [review]
add symbols for win32-metro

(In reply to Armen Zambrano G. [:armenzg] - Release Engineer from comment #5)
> Do I need any appending like on armv6?

This patch looks fine for dep builds (the env changes won't be used yet).

For nightlies you will probably need a MOZ_SYMBOLS_EXTRA_BUILDID defined to avoid the regular win32 desktop symbols. Once this patch gives you dep builds producing crashreporter-symbols.zip you can look inside one and see how the .txt file is named. The existing symbol manifests look like this
 firefox-16.0a1-WINNT-<buildid>-x86_64-win64-elm-symbols.txt
 firefox-16.0a1-WINNT-<buildid>-x86-elm-symbols.txt

Comment 8

[Aki Sasaki (not active)]

This landed in production yesterday, sorry for the delay in notification.

Comment 9

[Jim Mathies [:jimm]]

(In reply to Aki Sasaki [:aki] from comment #8)
> This landed in production yesterday, sorry for the delay in notification.

Should symbols for the metro build be available pulbically? I just checked the latest build from today and the debugger is reporting it can't get them.

Comment 10

[Armen [:armenzg]]

(In reply to Jim Mathies [:jimm] from comment #9)
> (In reply to Aki Sasaki [:aki] from comment #8)
> > This landed in production yesterday, sorry for the delay in notification.
> 
> Should symbols for the metro build be available pulbically? I just checked
> the latest build from today and the debugger is reporting it can't get them.

I landed a fix since we had defined packageTests twice: one to set it to True and the other to False.

Once this new change makes it to production we should symbols and package tests being generated.

Comment 11

[Aki Sasaki (not active)]

This made it to production today.

Comment 12

[Armen [:armenzg]]

We now have crashreport symbols and packaged tests:
http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/elm-win32-metro/1342117666

Comment 13

[Nick Thomas [:nthomas] (UTC+12)]

(In reply to Jim Mathies [:jimm] from comment #9)
> Should symbols for the metro build be available pulbically? I just checked
> the latest build from today and the debugger is reporting it can't get them.

If you mean the symbol server here then that will require enabling nightlies. Dep builds only create the crashreporter-symbols.zip for upload beside the bits, eg at the url Armen gave in comment #12.

Comment 14

[Jim Mathies [:jimm]]

(In reply to Nick Thomas [:nthomas] from comment #13)
> (In reply to Jim Mathies [:jimm] from comment #9)
> > Should symbols for the metro build be available pulbically? I just checked
> > the latest build from today and the debugger is reporting it can't get them.
> 
> If you mean the symbol server here then that will require enabling
> nightlies. Dep builds only create the crashreporter-symbols.zip for upload
> beside the bits, eg at the url Armen gave in comment #12.

What would it take to get those going with pdbs served up by the symbol server? The symbol files being zipped up for crashreporter are packaged in a format that is incompatible with Visual Studio.

Comment 15

[Nick Thomas [:nthomas] (UTC+12)]

Ted, do we have space on the symbol server to accommodate uploading dep builds there ? The alternative is something like this:

diff --git a/toolkit/mozapps/installer/packager.mk b/toolkit/mozapps/installer/packager.mk
--- a/toolkit/mozapps/installer/packager.mk
+++ b/toolkit/mozapps/installer/packager.mk
@@ -979,17 +979,21 @@ CHECKSUM_FILES = $(CHECKSUM_FILE)
 
 UPLOAD_FILES= \
   $(call QUOTED_WILDCARD,$(DIST)/$(PACKAGE)) \
   $(call QUOTED_WILDCARD,$(INSTALLER_PACKAGE)) \
   $(call QUOTED_WILDCARD,$(DIST)/$(COMPLETE_MAR)) \
   $(call QUOTED_WILDCARD,$(DIST)/$(LANGPACK)) \
   $(call QUOTED_WILDCARD,$(wildcard $(DIST)/$(PARTIAL_MAR))) \
   $(call QUOTED_WILDCARD,$(DIST)/$(PKG_PATH)$(TEST_PACKAGE)) \
+ifdef MOZ_METRO
+  $(call QUOTED_WILDCARD,$(DIST)/$(PKG_PATH)$(SYMBOL_FULL_ARCHIVE_BASENAME).zip) \
+else
   $(call QUOTED_WILDCARD,$(DIST)/$(PKG_PATH)$(SYMBOL_ARCHIVE_BASENAME).zip) \
+endif
   $(call QUOTED_WILDCARD,$(DIST)/$(SDK)) \
   $(call QUOTED_WILDCARD,$(MOZ_SOURCESTAMP_FILE)) \
   $(call QUOTED_WILDCARD,$(PKG_JSSHELL)) \
   $(if $(UPLOAD_EXTRA_FILES), $(foreach f, $(UPLOAD_EXTRA_FILES), $(wildcard $(DIST)/$(f))))
 
 SIGN_CHECKSUM_CMD=
 ifdef MOZ_SIGN_CMD
 # If we're signing with gpg, we'll have a bunch of extra detached signatures to

Which would get us uploading a crashreporter.zip with .pdb's as well as .sym files.

Comment 16

[(not currently active) Ted Mielczarek]

(In reply to Nick Thomas [:nthomas] from comment #15)
> Ted, do we have space on the symbol server to accommodate uploading dep
> builds there ? The alternative is something like this:

I don't think so, no. We've been skating on thin ice there for some time.

Comment 17

[Jim Mathies [:jimm]]

Can we do the alternative? I'm just interested in getting at pdbs for builds here - 

http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/elm-win32-metro/

so that I can debug these builds locally. I don't mind downloading the pdbs along with the zip install to do it.

Comment 18

[Nick Thomas [:nthomas] (UTC+12)]

Assuming that patch actually works (haven't tested it), you can land it in Elm. How long would you want that to last though, and when might Elm merge back to m-c ?

Comment 19

[Jim Mathies [:jimm]]

(In reply to Nick Thomas [:nthomas] from comment #18)
> Assuming that patch actually works (haven't tested it), you can land it in
> Elm. How long would you want that to last though, and when might Elm merge
> back to m-c ?

merging elm to mc is blocked on bug 755724. Once that's fixed we'll finish up the migration. Maybe within the next couple months. 

Currently on elm we have both vc10 and experimental vc11 builds going. At some point after the mc merge we'll need elm nightlies for the vc11 builds with symbols uploaded to the symbol server. At which point I guess this could be undone. Does this make sense?