627454 - Set up more re-usable project branches, and make the turn around on adding new ones faster

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

[Lukas Blakk [:lsblakk] use ?needinfo]

As we move into faster releasing there will be a need for more project branches to be signed out by teams working on features to push to trunk.  Using the current set up for the disposable project branches, this bug will track:

For both build & test configs:
1. Increasing the amount of project branches from the current number (3) to 17
2. Making the creating of config variables for this type of branch dynamically generated from a master list of current branch names so that adding more later is trivial
3. Having the mozconfigs for each project branch be auto-generated from a generic template - it would be ideal if the mozconfigs could be sourced from the project repo (I think there's a bug on this already?)

Also with regards to making the turnaround faster, we need to have the graphserver entries (stage & production) also generated and checked against a master list of project branch names.


What this will look like when the bug is considered fixed:

Using a branch when enough exist is RelEng hands-free
* Team leader books a repo on this page https://wiki.mozilla.org/DisposableProjectBranches and puts in the IT request for cloning or resetting the booked repo

If we run out of project branches to loan out and a new one is required:
* New RelEng bug requesting another project branch is added to the list
* add the new branch name to the list in config.py for build/test configs
* mozconfigs are auto-generated from generic template and ready for use
* graphserver polling script scans the list of branches, sees new branch name, inserts the required entries for that branch name to stage & production graphserver

Comment 1

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: Adds more project branches to the build/test configs & generics for branch vars

Comment 2

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: v.2 - now with generic mozconfig location for any project branch

Comment 3

[Lukas Blakk [:lsblakk] use ?needinfo]

Version 2 uses a generic mozconfig since the only difference in the project branch mozconfigs is the addition of:

if [ -f $topsrcdir/mozconfig-extra ] ; then
  . $topsrcdir/mozconfig-extra
fi
if [ -f $topsrcdir/mozconfig-extra-linux ] ; then
  . $topsrcdir/mozconfig-extra-linux
fi


to allow projects to add mozconfig-extra in order to alter what is used for their particular build needs.

This way, no mozconfigs need to be kept 'up to date' - all project branches will use these generic ones and do adjustments in their repo.

Comment 4

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

I like it! I'd suggest using the m-c mozconfigs for generic too, so that those two don't end up diverging. If hg on windows coped nicely with symlinks in the repo then we could symlink all the project branches back to m-c configs. Perhaps later versions than 1.2.1 work better ?

IIRC, that would leave just --enable-update-channel=nightly-foo divergences in tracemonkey and electrolysis, which I have a plan for making go away (either generated at build time or source branch-specific file).

Comment 5

[Chris AtLee [:catlee]]

Comment on attachment 505516 [details] [diff] [review]
v.2 - now with generic mozconfig location for any project branch

Does looking at dump_masters output show any changes to other branches?

Comment 6

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: data.sql update for new branches {build-system,services-central}

No rush on this, I will put the insert statements into IT bugs assigned to each new project branch bug for adding to staging-graphserver and graphserver

Comment 7

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: [needs testing] uses one file location for project branches

I'll test this with config output first thing on Monday morning, but right now it passes test-masters so that's exciting.  With this patch there's just a project_branches.py file in the mozilla/ dir and a symlink to it in mozilla-tests/ (just like master_common.py) and that way to add a new project branch you really do only need to change one line (or lines if custom repo) to see it everywhere.

Comment 8

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: newest version, tested

one file, also loads in repo_path from the project_branches location in case you are trying to override, and also adds build-system to active branches for bug 627414

Comment 9

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: fixed double 'repo_path' in mozilla-tests config.py

Comment 10

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: adds project_branches to setup-master

Comment 11

[Chris AtLee [:catlee]]

Comment on attachment 512927 [details] [diff] [review]
adds project_branches to setup-master

not required any more aiui

Comment 12

[Lukas Blakk [:lsblakk] use ?needinfo]

Update on this bug:

Currently adding a new branch requires the following human/bug steps:
* Add it to self-serve
* Add it to tbpl
* Create a tinderbox page
* Add it to project_branches.py and then turn it on in each builder master's localconfig (example https://bug635930.bugzilla.mozilla.org/attachment.cgi?id=514333)
* Add it to the data.sql file in graphs for backup purposes
* Run insert statements for the branch (based on the data.sql entries) on both graphserver-stage and production graphserver
* Create an empty macosx dir for the branch on stage
* Land & reconfig masters, enable scraping on Tinderbox

Things that would make this process easier and more automated:
* Self-serve should autoscrape the project_branches file for project names
* tbpl should autoscrape the project_branches (or check for commits to that file?)
* Shouldn't have to turn on the project branches in each localconfig - set it up so that ACTIVE_PROJECT_BRANCHES is set in project_branches.py and pulled in to localconfig instead
* Webform to submit new insert statements to the graphserver databases (bug 505803)
* That webform should also output the diff to add to data.sql
* Fix bug 634968 so that the dummy macosx dir isn't needed anymore

Comment 13

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: allow for disabling talos, and setting 'enable_unittests' in project_branches

Comment 14

[[e-mail] (:bhearsum)]

Comment on attachment 515780 [details] [diff] [review]
allow for disabling talos, and setting 'enable_unittests' in project_branches

Any reason we can't use "enable_talos"? I don't like the inconsistency between that and all the existing toggles we have. It especially looks confusing to see "enable_unittest" and "disable_talos" right next to each other, like in bug 635930.

Comment 15

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: allow for setting 'enable_talos' and 'enable_unittests' in project_branches.py

no problem, enable all the way :)

Comment 16

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 515935 [details] [diff] [review]
allow for setting 'enable_talos' and 'enable_unittests' in project_branches.py

http://hg.mozilla.org/build/buildbot-configs/rev/67013b0dc607

landed on default

Comment 17

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 511886 [details] [diff] [review]
data.sql update for new branches {build-system,services-central}

http://hg.mozilla.org/graphs/rev/b92334eb031c landed

Comment 18

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 512560 [details] [diff] [review]
fixed double 'repo_path' in mozilla-tests config.py

http://hg.mozilla.org/build/buildbot-configs/rev/3e34d406c490 landed

Comment 19

[Lukas Blakk [:lsblakk] use ?needinfo]

When bug 597087 is fixed, it will be possible to customize more about a project branch.

Comment 20

[Lukas Blakk [:lsblakk] use ?needinfo]

When the patch in bug 638132 lands, ACTIVE_PROJECT_BRANCHES in project_branches.py will maintain the list so that less files need editing to add a new project branch. 

However, I still need to make sure there is a staging-compatible version of project branches that doesn't upload to stage, and also uses MozillaTest tinderbox pages (bug 643467)

Comment 21

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Now that FF4.0 dust has cleared, the 3 current re-usable project branches are now all in use. 

Can we setup some new project branches? We've a deadline of 12apr coming, where I'd like a spare re-usable project branch to copy code from m-c for FF5.0... Its a contingency plan in case the other branch setup work is not done in time, but its good to have this as fallback plan.

Comment 22

[Lukas Blakk [:lsblakk] use ?needinfo]

> Can we setup some new project branches? 

more branches were added in bug 649190

also updated https://wiki.mozilla.org/ReleaseEngineering:ProjectBranchPlanning#Release_Engineering_Checklist

At this point RelEng and IT can both update TBPL so the only non-releng step in setting up a new branch is adding to the graphserver.  I'll push on bug 505803 more to see about getting something set up this quarter if possible.

Comment 23

[Lukas Blakk [:lsblakk] use ?needinfo]

Now that there is a web app in both production and staging to add machines & branches to graphserver (web UI and API) I'm closing this bug.