Don't use cros_mark_as_stable to push uprevs |
|||
Issue descriptionWe 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.
,
Dec 13
,
Dec 14
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.
,
Dec 14
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 ...
,
Dec 17
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 |
|||
Comment 1 by athilenius@chromium.org
, Dec 13