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

Issue 761906 link

Starred by 2 users

Issue metadata

Status: Verified
Owner:
Closed: Sep 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug

Blocked on:
issue 718420



Sign in to add a comment

Recipe Auto-roller not auto-rolling

Project Member Reported by tikuta@chromium.org, Sep 5 2017

Issue description

I updated ninja in depot_tools for faster compile time on buildbot.
https://chromium-review.googlesource.com/648372

But that does not directly update depot_tools used in buildbot.
This is request to update recipes.cfg for depot_tools.
https://cs.chromium.org/chromium/infra/infra/config/recipes.cfg

 
Cc: dpranke@chromium.org
cf thread "How to update depot_tools in .recipe_deps used in buildbot".

tikuta  updated ninja in depot_tools several hours ago.
https://chromium-review.googlesource.com/648372

It's still not used apparently; it sounds like the recipe roller is stuck or something. (Is there monitoring for it?)

The process for ninja rolls is "land, watch tree, revert in case of problems". If there's an unpredictable, hour (or day) long delay between landing and the binary being used on bots, that's kind of suboptimal.
Cc: aga...@chromium.org
Labels: Infra-Troopers
Summary: Recipe Auto-roller not auto-rolling (was: Request for update depot_tools used in buildbot)
Changing the subject from "Request for update depot_tools used in buildbot" to "Recipe auto-roller not auto-rolling". 

This is a trooper-level problem.
Owner: aga...@chromium.org
Status: Started (was: Untriaged)
Note for the future: the "external" link in the autoroller docs is broken: https://chrome-internal.googlesource.com/infra/infra_internal/+/master/doc/services.md#Recipe-autoroller
It looks like the autoroller *is* running ((https://uberchromegw.corp.google.com/i/internal.infra.cron/builders/recipe-autoroller-internal/builds/67854 is red, but only for skia -- the steps for infra / build / depot_tools all succeed) and it has recently updated the recipes.cfg file pointed to in the 0th comment (https://chromium.googlesource.com/infra/infra/+/ca6275d670533aaf5303bd2c785cb7366fbe3193 updates the pinned hash for build).

It hasn't updated the hash for depot_tools since the 1st, though (https://chromium.googlesource.com/infra/infra/+/82aba0d309c103f7b872117665821b3080979899), probably because it doesn't think it needs to.

To the best of my knowledge, the recipe roller only updates the pinned hash when it thinks there has been a *recipes* change that it needs to roll. The version of ninja isn't a recipes change, so it hasn't updated the pin for depot_tools.

Robbie, does that agree with your knowledge of how things work?
Blockedon: 718420
The reason this didn't roll is that no "recipe files" were affected. Right now the heuristic for this is extremely dumb (namely: "have any files inside the recipes subdirectory changed?"). This has come up before: https://bugs.chromium.org/p/chromium/issues/detail?id=718420#c3

(marking it as blocked by this for visibility, but it's not really blocked, it can be manually resolved)
> To the best of my knowledge, the recipe roller only updates the pinned hash
> when it thinks there has been a *recipes* change that it needs to roll. 

If so, that's a bug somewhere, since the ninja binaries are effectively resources 
needed by the recipe modules in the repo. That said, I could've sworn I'd seen the 
roller roll things for patches unrelated to recipes recently ...

> The version of ninja isn't a recipes change, so it hasn't updated the pin 
> for depot_tools.

At this point, should we try to update dependencies manually?

Also, how would this even work for changes to the bot_update and gclient modules, 
since gclient.py isn't in one of those subdirectories?
So it used to be the case that recipes were 'the whole' of depot_tools (i.e. there was no recipes subdir). This meant that every change to depot_tools was 'interesting' from the roller's pov. At some point this was changed so that recipes went into a subfolder (because otherwise there was a confusing 'recipes.py' on everyone's $PATH).

We now have a mechanism for expressing recipe-important resources outside of the recipes folder (i.e. this stuff: https://chromium.googlesource.com/chromium/tools/depot_tools/+/master/.gitattributes), but it's not wired up to the autoroller's sense of of what's important (it SHOULD be, however). These gitattributes are currently used for recipe bundling (what `led` invokes to make a recipe bundle).
Project Member

Comment 9 by bugdroid1@chromium.org, Sep 5 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/tools/build/+/65ff2ecbe8170336176318e75b1f51ebab07d0cd

commit 65ff2ecbe8170336176318e75b1f51ebab07d0cd
Author: Aaron Gable <agable@chromium.org>
Date: Tue Sep 05 17:55:09 2017

Manually roll depot_tools recipes pin to pick up ninja v1.8.0

R=iannucci@chromium.org, tikuta@chromium.org

Bug:  761906 
Change-Id: I450c2e5f9e70832b10d9dc4e7d97cf2449f33bab
Reviewed-on: https://chromium-review.googlesource.com/650528
Reviewed-by: Robbie Iannucci <iannucci@chromium.org>
Commit-Queue: Robbie Iannucci <iannucci@chromium.org>

[modify] https://crrev.com/65ff2ecbe8170336176318e75b1f51ebab07d0cd/scripts/slave/README.recipes.md
[modify] https://crrev.com/65ff2ecbe8170336176318e75b1f51ebab07d0cd/infra/config/recipes.cfg

Status: Fixed (was: Started)
The above change has been picked up by the autoroller and propagated into infra and other repos.
Status: Verified (was: Fixed)
Thanks!

Sign in to add a comment