New issue
Advanced search Search tips

Issue 904936 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: 2
NextAction: ----
OS: Chrome
Pri: 1
Type: Feature

Blocked on:
issue 912361

Blocking:
issue 904881


Show other hotlists

Hotlists containing this issue:
CrOSParallelCQ


Sign in to add a comment

Port uprev step in cbuildbot stage to build_api

Project Member Reported by cindyb@google.com, Nov 13

Issue description

Uprev ebuilds based on CL changes (cros_mark_as_stable)
 - existing scripts

 
Status: Available (was: Untriaged)
Owner: saklein@chromium.org
Status: Assigned (was: Available)
Components: Infra>Client>ChromeOS>Build
Summary: Uprev as a discrete step (for parallel CQ recipes) (was: Uprev)
EstimatedDays: 2
Blockedon: 912361
Cc: nednguyen@chromium.org
This should be a pretty simple one. We haven't fully finalized the foundations yet, but it should be getting close.
Cc: -nednguyen@chromium.org saklein@chromium.org
Owner: nedngu...@google.com
I will take this bug (with saklein@'s help) to get more familiarity of the system 
See also crbug.com/914988
A couple of notes....

Uprev requires a chroot.

It is board specific, but easy do do for all boards. Doing it for all boards does affect performance.
Cc: la...@chromium.org
Summary: Port uprev step in cbuildbot stage to build_api (was: Uprev as a discrete step (for parallel CQ recipes))
Tweak the title a bit.. Let me know if anyone disagrees
We already have a prototype that just calls into the existing script, so porting to the Build API does not block Parallel CQ.

Per crbug.com/914988 we would *prefer* to have an option to do the actual commit pushes from the recipe rather than bundled into the `cros_mark_as_stable push` subcommand, but that does not strictly block us either.

Sign in to add a comment