No test packages (except jsshell) get uploaded for release builds

RESOLVED WONTFIX

Status

()

Firefox
Build Config
--
major
RESOLVED WONTFIX
2 years ago
2 years ago

People

(Reporter: whimboo, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [qa-automation-wanted])

(Reporter)

Description

2 years ago
So firefox-ui-tests moved into mozilla-central now and will ride the trains. As result the github repository will go away at some point in the future. 

That means for any kind of release testing we would need the common.tests.zip file beside release builds (this included also candidates and is both for beta and release). Right now this test file is not present on the FTP server for the en_US build.

I talked with Ben on IRC... so here our conversation:

<whimboo> so its just about http://ftp.mozilla.org/pub/firefox/candidates/44.0b9-candidates/build1/
<bhearsum> your goal is to get common.tests.zip uploaded as part of en-US builds?
<whimboo> and that its missing the test packages
<whimboo> yes
<bhearsum> okay
<bhearsum> so you need two things for that to happen
<whimboo> i can file a release automation bug then
<bhearsum> 1) the package must be generated
<bhearsum> you probably want to do that as part of "make package-tests"
<bhearsum> 2) the package must be in UPLOAD_FILES
<bhearsum> all of this can (and probably should) be done in the build system

Given that this is only a problem for release automation, there must be a specific if condition or such which excludes test packages right now.

If we cannot get this fixed in time we will no longer be able to run any kind of tests on final release builds with mozmill ci because we don't have access to the tests. We would only run tests for the tinderbox builds on the beta/release branches.

Maybe a workaround for now would be to somehow retrieve the tests by using the parent changeset of the release tags, and retrieve the test package via the tinderbox build. But this is not really something I would prefer.
This is almost certainly an issue in the build system...most likely there's a difference in how some variables are set depending on whether MOZ_PKG_PRETTYNAMES=1 is set or not. Or maybe one of the MOZ_AUTOMATION_* vars is different? Those should be printed at the top of the build logs.

For reference, here's the nightly and release mozconfigs:
https://dxr.mozilla.org/mozilla-central/source/browser/config/mozconfigs/linux64/nightly
https://dxr.mozilla.org/mozilla-central/source/browser/config/mozconfigs/linux64/release
Component: Release Automation → Build Config
Product: Release Engineering → Firefox
QA Contact: bhearsum
(Reporter)

Comment 2

2 years ago
So I wonder if this behavior is wanted. Maybe Rail or Nick can shed some light in here? If that would be the case and this bug ends up as wontfix, the workaround as explained above seems to work great for me locally. So it's not a definitive blocker for us.
Flags: needinfo?(rail)
Flags: needinfo?(nthomas)
Whiteboard: [qa-automation-blocked] → [qa-automation-wanted]
Release builds are a bit different and they will be going away "very soon" (TM) :)

They don't upload test packages, because we don't schedule any tests after them.
Flags: needinfo?(rail)
(Reporter)

Comment 4

2 years ago
Rail and I discussed that on IRC and with release promotion no extra builds will be generated anymore. That means the release will be a per checkin generated build which will have test packages available. 

Lets close this bug as wontfix.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Flags: needinfo?(nthomas)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.