New issue
Advanced search Search tips

Issue 914988 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: 5
NextAction: ----
OS: ----
Pri: 2
Type: Feature

Blocking:
issue 904950


Show other hotlists

Hotlists containing this issue:
CrOSParallelCQ


Sign in to add a comment

Don't use cros_mark_as_stable to push uprevs

Project Member Reported by athilenius@chromium.org, Dec 13

Issue description

We would prefer to not use `cros_mark_as_stable push` to push the uprevs generated by `cros_mark_as_stable commit`. Instead it would be better to use Recipe to do the actual pushes and add a `cros_mark_as_stable list-changes` command (or something like it) to support that.
 
Blocking: 904950
Labels: Disable-Nags CrOSParallelCQ Hotlist-CrOSParallelCQ
Cc: vapier@chromium.org
No strong opinion.

Just throwing out my view of the world.

I think that builds testing CLs should use "cros_workon" instead of "local uprevs" for the test build. This would make it more explicit that the versions built weren't "real" ebuild versions.

Then cros_mark_as_stable should uprev and push all as atomic (ish) step.
to the original comment: sure, pulling out "push" functionality sounds fine.

to Don's thoughts: the argument for doing an uprev and building that is two fold:
- when the bots are publishing prebuilts, we need to do this.  with post submit publishing prebuilts, that's no longer an issue.
- keeping the stuff we test in the CQ as close as possible to what everyone else sees (postsubmit/release/etc...).  we do some things differently when it's a 9999 ebuild.

we could arguably focus on making the 9999 code path more like non-9999 ...
Fair. I'm not sure if the benefits of using "cros_workon" are worth the effort, it just seems to me that it would make things conceptually cleaner.

Sign in to add a comment