Add an option to choose the life time of a build on try server via the try chooser

RESOLVED WONTFIX

Status

Release Engineering
General
P5
enhancement
RESOLVED WONTFIX
8 years ago
5 years ago

People

(Reporter: mounir, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [tryserver])

(Reporter)

Description

8 years ago
Sometimes, we want to keep a build for testing (like when asking a ui-review or asking users to test a specific thing that is not pushed) but sometimes, we just don't care and want to have tests results only.

It would be nice if, via the try chooser, we could choose how long we want to have the build available. We could imagine that it would default to X and will have 1 day minimal and Y days maximum.

I would tend to think that 1 day would be enough as a default value and 30 days seem reasonable as a maximum value. However, I guess we should keep the current default value as long as try chooser rules aren't mandatory when pushing to try?
(Reporter)

Updated

8 years ago
Blocks: 572808
Whiteboard: [tryserver]
What is the impediment of that build to be put in another server? e.g. people.m.o
/me looks around for his people.m.o login information...

The fact that not every contributor has a people.m.o account?
(Reporter)

Comment 3

8 years ago
And even, copy-pasting all builds might take some time (and after that, it would require to delete them). Doing that automatically would be much more nicer.
Even though every time I have brought this up before, it's been seen as an attempt to get to keep a build longer than you are letting us, it's really about two things: first, getting rid of the waste of resources from keeping 99% of the try builds around longer than it takes to run tests, because it's incredibly rare to want or have anyone at all other than test machines download a try build, and then, with the resources that frees up, keep the 1% that are actually tryservered to make builds available for human testing around longer.
volkmar this requires a lot of decisions, work and testing for little the gain.
Patches are welcomed and discussing issues as well. Unless, someone from releng has strong desires to fix this I would need a volunteer from outside of releng, otherwise, I would suggest to WONTFIX it as this can be easily worked around by downloading the builds somewhere else.

@philor your input had been greatly appreciated for that and helped us understand the real use case scenarios. Thanks again.
Priority: -- → P5
Severity: normal → enhancement
It's been a while since this bug was in discussion and at this point I would venture to say that the project branches (disposable, and long term) are the place to look to for keeping builds around that need human testing - the new ux branch is a good example.  

There's not much resource-saving to be had (as we're only talking disk space, not build time) to justify the work on doing something like this and I would even argue that try builds should not be held on to on our servers anyway as they are not signed and untested by large audiences.  The try builds should really just be for testing code changes, project branches are available for spinning up a temporary or long-term feature that needs user testing.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
(Assignee)

Updated

5 years ago
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.