Closed Bug 831483 Opened 13 years ago Closed 9 years ago

generating ASAN builds on release branch(es)

Categories

(Release Engineering :: General, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: joduinn, Unassigned)

References

Details

(Keywords: sec-want, Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2309] )

spinning out of bug#753148. bug#753148 is about running ASAN builds on mozilla-central (and maybe try). Whether we should also generate ASAN builds on mozilla-aurora and/or mozilla-beta and/or mozilla-release is unclear. :decoder would not be using aurora/beta/release, but he thinks that QA would. Filing this bug to track discussion, and if there is a need, to track doing the work of enabling ASAN builds on these extra branches.
I talked to :dveditz about this and he said that release in particular is probably least useful. According to him, beta would be most valuable right now for QA and he wasn't sure about Aurora. Ccing him so we can sort out the details.
Christian, do you just care about having ASan builds from the same changesets as releases?
This is probably a question that either :abillings, :dveditz or QA people can answer much better than me, since I don't use any ASan release builds.
(In reply to Christian Holler (:decoder) from comment #3) > This is probably a question that either :abillings, :dveditz or QA people > can answer much better than me, since I don't use any ASan release builds. I know David Bolter isn't in this list of people, but I happened to see him around the office and neither of us could figure out a reason why we need more than "ASan builds from the same revision as releases". If this is indeed true it _should_ be as easy to set-up as the original ones.
Component: Release Engineering: Automation (Release Automation) → Release Engineering: Automation (General)
QA Contact: bhearsum → catlee
Generally, we want them so QA and others can verify "X ASAN bug *is* in the released 18.0.1 because I checked that ASAN build." Unless you're doing a regression range, that is good enough to check affected versions of Firefox.
OK, so it sounds to me like builds from the same revisions (provided they exist in perpetuity) satisfies this use case just fine.
Product: mozilla.org → Release Engineering
(In reply to Ben Hearsum [:bhearsum] from comment #6) > OK, so it sounds to me like builds from the same revisions (provided they > exist in perpetuity) satisfies this use case just fine. I think this is right - it is as close as we can get. So I guess this bug boils down to making sure the ASAN builds with same revision as release get stored somewhere. We could also just build them on demand I suppose. Matt what would help your workflow best?
Flags: needinfo?(mwobensmith)
I agree with Ben in comment 6. Having them exist in perpetuity - from the same revisions - is very useful, for QA and other parties also. We can always build our own when needed, but this is still hugely convenient.
Flags: needinfo?(mwobensmith)
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2306]
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2306] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2309]
We have been doing ASAN builds on beta and release for a while now. I think that means this is fixed.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Component: General Automation → General
You need to log in before you can comment on or make changes to this bug.