| commit | b82054e1d929cdff567df166edf927361181bf67 | [log] [tgz] |
|---|---|---|
| author | Robbie Iannucci <iannucci@chromium.org> | Mon Sep 30 18:06:38 2019 |
| committer | Commit Bot <commit-bot@chromium.org> | Mon Sep 30 18:06:38 2019 |
| tree | 017bf01a68f128b44f29056f81f439781a5ae28e | |
| parent | 88c098c1d36351d6b551c604122ddb27236b2038 [diff] |
Revert "[step] Improve cost model to cover memory, disk and network resources, too." This reverts commit 88c098c1d36351d6b551c604122ddb27236b2038. Reason for revert: Produces too much noise in expectations for no-cmd and parent nest steps. Original change's description: > [step] Improve cost model to cover memory, disk and network resources, too. > > I realized that since we're not actually acquiring the resources > individually, the 'resource vector' can actually cover as many aspects of > the machine as we like, and we won't deadlock (since in the worst case > steps will be serialized as they each wait for enough resources to become > available). > > I plan to use this to model the `git gc --aggressive` action in terms of > memory+cpu+disk usage, based on the size of the repo after it's been > fetched. > > I punted on modeling disk and network cost in terms of concrete units; > This would require a pretty messy and inaccurate collection of syscalls, > not to mention accounting for multiple disks, different network hosts or > varying network conditions. Modeling them as percentages should be good > enough, I think, for most use cases (e.g. "not much", "a little", "a lot", > "all of it"). > > I have the default of (1/2 core + 50MB) for steps, as I thought that > would be a reasonable starting point and should help throttle completely > crazy numbers of parallel steps from overwhelming the machine (by default). > Users who want craziness can always pass 'cost=None'. > > R=tandrii@chromium.org > > Recipe-Nontrivial-Roll: build > Recipe-Nontrivial-Roll: build_limited_scripts_slave > Recipe-Nontrivial-Roll: chromiumos > Recipe-Nontrivial-Roll: depot_tools > Recipe-Nontrivial-Roll: fuchsia > Recipe-Nontrivial-Roll: infra > Recipe-Nontrivial-Roll: release_scripts > Change-Id: Ied8fc0ef0046afc6ab378c4bcf64bbd70a09f6c1 > Reviewed-on: https://chromium-review.googlesource.com/c/infra/luci/recipes-py/+/1831236 > Commit-Queue: Robbie Iannucci <iannucci@chromium.org> > Auto-Submit: Robbie Iannucci <iannucci@chromium.org> > Reviewed-by: Andrii Shyshkalov <tandrii@google.com> TBR=iannucci@chromium.org,tandrii@google.com Change-Id: I5993f1cb9eb0e4dbb85fbc655ccddf785f344263 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/infra/luci/recipes-py/+/1831987 Reviewed-by: Robbie Iannucci <iannucci@chromium.org> Commit-Queue: Robbie Iannucci <iannucci@chromium.org>
Recipes are a domain-specific language (embedded in python) for specifying sequences of subprocess calls in a cross-platform and testable way.
They allow writing build flows which integrate with the rest of LUCI.
Documentation for the recipe engine (including this file!). Take a look at the user guide for some hints on how to get started. See the implementation details doc for more detailed implementation information about the recipe engine.
user.email and user.name are configured in git config.Run the following to setup the code review tool and create your first review:
# Get `depot_tools` in $PATH if you don't have it git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git $HOME/src/depot_tools export PATH="$PATH:$HOME/src/depot_tools" # Check out the recipe engine repo git clone https://chromium.googlesource.com/infra/luci/recipes-py $HOME/src/recipes-py # make your change cd $HOME/src/recipes-py git new-branch cool_feature # hack hack git commit -a -m "This is awesome" # This will ask for your Google Account credentials. git cl upload -s -r joe@example.com # Wait for approval over email. # Click "Submit to CQ" button or ask reviewer to do it for you. # Wait for the change to be tested and landed automatically.
Use git cl help and git cl help <cmd> for more details.