New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 22158 link

Starred by 32 users

Issue metadata

Status: Fixed
Owner:
Email to this user bounced
Closed: Aug 2010
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Feature
M-7

Blocked on:
issue 34471
issue 48921

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Daily Auto-Updating Google Chrome Build

Project Member Reported by lafo...@chromium.org, Sep 17 2009

Issue description

Right now our crash data is lagging approximately 1-2 weeks behind our current tip of tree.  This is causing us problems 
finding regression points, iteratively attempting fixes, and making more aggressive use of CHECKS.  More over it would be 
helpful in getting the software in our users hands more rapidly to help find feature breaks (and see when feature defects 
have been cured w/ out waiting a week or two for the next dev cycle)

Proposal:

Build a breakpad enabled chromium build along side the standard chromium builds (revision for revision), and store in the 
outputs in a non-public archive.

The auto-update mechanism:
Right now http://build.chromium.org/buildbot/continuous/win/LATEST/REVISION, which represents the last all green is 
updated by a chron script.  When the chron build executes and finds a green build, it would update a special 
LATEST/REVISION location w/ the new version and mini-installer binaries (this special update would happen no more than 
once a day).  Since we have the matching compiled binaries this would effectively be a copy.

The special chromium build would "auto-update" by polling (5 hour interval, startup, etc...) on this special 
LATEST/REVISION location and install mini-installer

Crash reporting:

We'd report crashes back in a way that would specially indicate the source of the chromium build (i.e. a specific product 
or version moniker)

TBD (offline discuss):
Since data collection is involved, we'd need to figure out how we will manage the EULA and at what point this would occur.
 

Comment 1 by mar...@chromium.org, Sep 17 2009

I'd rather have a single build and an opt-out (opt-in at worst) on installation.

Otherwise, it's just yet another set of slaves to maintain.
We don't do reporting, google update does. If you want this, you need to find a way to 
get google update installed.

Comment 3 by mar...@chromium.org, Sep 17 2009

@nsylvain, Integrate http://code.google.com/p/omaha/ ?
That's probably non-trivial and probably requires some sort of "interactive install".

Comment 4 by huanr@chromium.org, Sep 17 2009

Labels: -Area-Misc Area-Infrastructure
Add Kuchhal.

Comment 5 by jon@chromium.org, Sep 24 2009

Status: Assigned
Short term:
  1.  Official build-bot that runs nightly using the CL for the latest green Chromium build.
  2.  Builds are stored in a convenient location where QA can use them for validation.
  3.  Builds are not signed.
  4.  Builds can be installed along-side Stable, Beta, or Dev channel releases without side-effects.
  5.  Builds have unique branding that distinguishes them as dangerous/untested/scary.
  6.  Public release via web server or not at all.  May be internal only.
  7.  Manual updates.

Medium Term:
  1.  Unique product ID. (so we don't pollute the config for the updater)
  2.  Updates via normal updater.
  3.  Updates hosted on production systems for download.
  4.  Everything automated except approval of the config for the updater. (no updates on holidays/weekends?)
  5.  Binaries available to the public.

Long Term:
  1.  Builds are signed.
  2.  Build official releases without scary branding in parallel for quick and easy released when blessed by 
QA.


For short term goals, I don't see anything about how to get the crashes reported back 
to us. How do we intend to achieve isolation of Google Chrome daily build from 
dev/beta/channel builds? If we use regular installer, they do end up installing in the 
same place. One way out could be to just provide a zipped file that user will extract 
somewhere and launch chrome.exe. But in this case I am not sure how do we get breakpad 
integration (doesn't look like it could be through Omaha) for crash reporting. 

Comment 7 by jon@chromium.org, Oct 22 2009

Labels: -mstone-4 mstone-5
This should not block mstone-4 so unless it is already in code review it 
should be in mstone-5.

Comment 8 by jon@chromium.org, Nov 3 2009

Status: Untriaged
Status: Assigned
The goal here is pretty big. Maybe we need some bugs to track finer grained tasks 
needed to make this happen?

Comment 10 Deleted

Comment 11 by keic...@gmail.com, Nov 7 2009

proposal:
theres an fanatical option in the about menu of chrome that is make default to check 
each successful version of chrome in 
http://build.chromium.org/buildbot/continuous/win/LATEST/REVISION and download the 
latest http://build.chromium.org/buildbot/continuous/LATEST/mini_installer.exe in the 
background and execute it for background install every second there was a successful 
build. I know there are congested issues that will occur here in google servers, why 
not make a torrent that will use other peoples bandwidth for sharing.

I always check and download every revision every 5 minutes because i am a fanatical 
user of successful builds up to the last second. Why not make that an option for 
people like us.

Real time updates indeed will be a server congestion, but its a simple price to pay 
for innovation, just like twitter does, tweet. why not make the updates tweet too.

just a thought.

Comment 12 by huanr@chromium.org, Nov 17 2009

After talk with people, there are two things people want: (a) being able to 
install/update chromium daily build with crash reporting provided, (b) ability to 
build/release/update an official build that can be installed/updated side by side 
with current stable/beta on user's machine.

a. Chromium update with crash reporting:

1. Build system. The current buildbot system has everything we need to get started. 
Some notes:
  - The chromium builds are archived at http://chrome-web/buildbot/snapshots/. We 
will use chromium_rel_xp.
  - The corresponding symbols for chromium_rel_xp symbols are uploaded to crash 
server by reliability bot.
  - We need a way to publish daily known good revision. Current mechanisms:
    - The revision published at http://chrome-web/buildbot/snapshots/chromium-rel-
xp/LATEST is updated every time a new chrome_rel_xp is built. 
    - The revision published at http://chromium-status.appspot.com/lkgr is updated 
every time the unit tests passes on all 3 platforms.
    - The revision for daily official build is selected at 3AM and a notification is 
sent to chrome-releases@google.com. This one is closest to what we need but there 
might not be a corresponding chrome_rel_xp build with the same revision. We could 
consider finding the chromium_rel_xp build with closest revision and publish the 
revision somewhere.

2. Provide a simple update binary that fetches installer from the server and runs it.
  - Be able to update to the specified revision or the last known good revision.
  - Add auto update functionality if needed.

3. Provide a Chromium extension to user that does the following:
  - Notify the user when a newer daily release is present so she can exit browser and 
run updater.
  - When user downloads and installs the extension, present Eula so user can agree to 
send crash report to Google.
  - Ideally we want the URL that crash reports are sent to configurable.
  - See the mock done by hbridge for UI.

4. Modify Chromium code so that it performs in-proc crash reporting if the above 
extension exists and is enabled.
  - This does not work with renderer process with sandbox enabled. It is ok for now.
  - When sending the crash dumps, we can append the version with revision number when 
filling in the version field so crash dumps from different revisions are separated in 
crash query server.


b. Add an official build option that can be installed/updated side by side with 
current stable/beta on user's machine.

1. Change build system so it can build with this new branding.

2. Side by side install/update with Google Chrome and Chromium.
  - Install to different path.
  - Make sure setting default browser handle the new branding correctly.


I will file individual bugs for above items.

Comment 13 by huanr@chromium.org, Nov 17 2009

Blockedon: 27926 27928 27929 27930 27931 27933
This confuses me.

You want an "official/optimized" "chromium" build?

And you want to change the branding?



The build optimization types are illnamed.

Comment 16 by huanr@chromium.org, Nov 25 2009

Labels: Stability
Labels: -Area-Infrastructure Area-BuildTools
Labels: Area-Internals Internals-Install
Labels: -Area-Internals -Internals-Install
Fixing a bulk edit. Looks like the search query was not correct.

Comment 20 by huanr@chromium.org, Mar 24 2010

Blockedon: -27926 -27928 -27929 -27930 -27931 -27933 34471

Comment 21 by huanr@chromium.org, Mar 24 2010

Labels: -mstone-5 Mstone-6 Area-Internals
Summary: Daily Auto-Updating Google Chrome Build
Will revisit the issue after side by side is done.

Comment 22 by huanr@chromium.org, Jul 13 2010

Blockedon: 48921

Comment 23 by huanr@chromium.org, Jul 24 2010

Labels: -Mstone-6 Mstone-7

Comment 24 by mal@chromium.org, Jul 28 2010

canary build updates daily now. fixed?
Status: Fixed

Comment 27 by keic...@gmail.com, Aug 8 2010

how about chromium build?
Labels: -Area-BuildTools bulkmove Area-Build
Right now our crash data is lagging approximately 1-2 weeks behind our current tip of tree.  This is causing us problems 
finding regression points, iteratively attempting fixes, and making more aggressive use of CHECKS.  More over it would be 
helpful in getting the software in our users hands more rapidly to help find feature breaks (and see when feature defects 
have been cured w/ out waiting a week or two for the next dev cycle)

Proposal:

Build a breakpad enabled chromium build along side the standard chromium builds (revision for revision), and store in the 
outputs in a non-public archive.

The auto-update mechanism:
Right now http://build.chromium.org/buildbot/continuous/win/LATEST/REVISION, which represents the last all green is 
updated by a chron script.  When the chron build executes and finds a green build, it would update a special 
LATEST/REVISION location w/ the new version and mini-installer binaries (this special update would happen no more than 
once a day).  Since we have the matching compiled binaries this would effectively be a copy.

The special chromium build would "auto-update" by polling (5 hour interval, startup, etc...) on this special 
LATEST/REVISION location and install mini-installer

Crash reporting:

We'd report crashes back in a way that would specially indicate the source of the chromium build (i.e. a specific product 
or version moniker)

TBD (offline discuss):
Since data collection is involved, we'd need to figure out how we will manage the EULA and at what point this would occur.
Project Member

Comment 29 by bugdroid1@chromium.org, Oct 13 2012

Blockedon: -chromium:34471 -chromium:48921 chromium:34471 chromium:48921
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 30 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Mstone-7 -Area-Internals -Area-Build M-7 Cr-Internals Build
Project Member

Comment 31 by bugdroid1@chromium.org, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Labels: hasTestcase

Sign in to add a comment