Preinstall packages in mock build environments

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
6 years ago
10 months ago

People

(Reporter: glandium, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2861] )

(Reporter)

Description

6 years ago
We're spending around 5 minutes on each linux build to install rpm packages in the mock environments, that could very well be installed once and for all.
Component: Release Engineering: Automation (Release Automation) → Release Engineering: Automation (General)
QA Contact: bhearsum → catlee
We can probably do this for a lot of things, but it gets a little trickier when we have changes riding trains (eg, new gcc). We have to make sure that each branch is still able to replace/remove packages to get in its proper state. Certainly things like autoconf, ccache, zip, etc. could be preinstalled.
Whiteboard: [buildfaster:?]
I'm not sure what you are using to install packages, but if it involves extracting archives, it's probably a bit heavyweight. You could use something like GNU stow to manage symlinks instead.
Whiteboard: [buildfaster:?]
(Reporter)

Comment 3

6 years ago
(In reply to Ben Hearsum [:bhearsum] from comment #1)
> We can probably do this for a lot of things, but it gets a little trickier
> when we have changes riding trains (eg, new gcc).

Our gcc packages are co-installable and don't step on each other. I'm in fact requesting that gcc 4.7 is installed in mock build environments so that we can use it for asan, dxr and try builds, and switch to it for m-c whenever we're ready.
(In reply to Ben Hearsum [:bhearsum] from comment #1)
> We can probably do this for a lot of things, but it gets a little trickier
> when we have changes riding trains (eg, new gcc). We have to make sure that
> each branch is still able to replace/remove packages to get in its proper
> state. Certainly things like autoconf, ccache, zip, etc. could be
> preinstalled.

we can version our mock configs if we have to
If we take the approach of expanding the set of base packages installed (which are cached in the root cache), the 'git' package would be a good candidate:

using mozilla-centos6-x86_64, git pulls in 24 packages
using mozilla-f16-i386, git pulls in 41 packages
This likely isn't the best bug to discuss this, but I'd eventually like to see the mock configs be part of the tree or at least be publicly usable (so anybody can reproduce the build environment being used by Mozilla). I'll happily file a new bug if one isn't on file.
Product: mozilla.org → Release Engineering

Updated

4 years ago
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2854]

Updated

4 years ago
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2854] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2859]

Updated

4 years ago
Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2859] → [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2861]
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
(Assignee)

Updated

10 months ago
Component: General Automation → General
Product: Release Engineering → Release Engineering
You need to log in before you can comment on or make changes to this bug.