[fuchsia_roller] Remove backwards roll check

commit 1fdf1df577ac9d565cd331b380e13d087bfa751a updated this recipe to
use the `multi-repo-roll-resolver` tool to determine which commits to
roll. This had the side effect that the recipe now ignores the
Buildbucket triggering commit, and instead rolls all unrolled commits on
the triggering branch of the repositories that it rolls.

However, the builders that use this recipe still triggers on every
commit, so we can run into a situation where:
1. Three commits land in a short window.
2. The builder triggers on the first of the three commits, but rolls all
   three commits.
3. The builder triggers on the middle commit, which hits the backwards
   roll detection because the triggering commit is different from the
   currently pinned version, but precedes it in the git history.
4. This triggers the backwards roll handling, causing the build to
   infra-fail, e.g. https://ci.chromium.org/b/8713115291013728353.

The backwards roll check is really only necessary to prevent the recipe
from actually rolling the repository backwards, but since we can tell
that the commit has already been rolled, it's fine to just exit the same
as we would if the triggering commit was equal to the current pinned
revision.

Change-Id: I89f98c82334eeda140593407f26bbc8eea18e72a
Reviewed-on: https://fuchsia-review.googlesource.com/c/infra/recipes/+/1291524
Fuchsia-Auto-Submit: Oliver Newman <olivernewman@google.com>
Commit-Queue: Oliver Newman <olivernewman@google.com>
Reviewed-by: Carver Forbes <carverforbes@google.com>
2 files changed
tree: 02c61bbcb38a8ac60ea828882bf8cfcdb940dae0
  1. git-hooks/
  2. infra/
  3. recipe_modules/
  4. recipe_proto/
  5. recipes/
  6. scripts/
  7. .editorconfig
  8. .git-blame-ignore-revs
  9. .gitignore
  10. AUTHORS
  11. LICENSE
  12. OWNERS
  13. PATENTS
  14. pyproject.toml
  15. README.md
  16. recipes.py
  17. shac.ensure
  18. shac.star
  19. shac.textproto
  20. shac_internal.star
  21. TOOLCHAIN_OWNERS
README.md

Fuchsia Recipes

This repository contains recipes for Fuchsia.

A recipe is a Python script that runs a series of commands, using the recipe engine framework from the LUCI project. We use recipes to automatically check out, build, and test Fuchsia in continuous integration jobs. The commands the recipes use are very similar to the ones you would use as a developer to check out, build, and test Fuchsia in your local environment.

See go/fuchsia-recipe-docs for complete documentation and a guide for getting started with writing recipes.

Getting the code and setting up your environment

For everyday development

The recommended way to get the source code is with jiri. A recipe will not run without vpython and cipd, and using these recommended jiri manifests will ensure that you have these tools.

You can use the fuchsia infra Jiri manifest or the internal version (Googlers-only). Once that manifest is imported in your local jiri manifest, jiri update should download vpython and cipd into <JIRI ROOT>/fuchsia-infra/prebuilt/tools/. If you add that directory to your PATH, you should be good to go.

Quick changes

If you're just trying to make a single small change to in this repository and already have your local environment set up for recipe development (e.g. because you work with another recipes repository) you can simply clone this repository with git:

git clone https://fuchsia.googlesource.com/infra/recipes

Then it will be up to you to ensure that vpython and cipd are available in your PATH.

Code formatting

We format python code using Black, an open-source Python autoformatter. It should be in your PATH if you followed the instructions for setting up your environment.

After committing recipe changes, you can format the files in your commit by running black . in your project root.

Many editors also have a setting to run Black automatically whenever you save a Python file (or on a keyboard shortcut). For VS Code, add the following to your workspace settings.json to make your editor compatible with Black and turn on auto-formatting on save:

{
    "python.formatting.provider": "black",
    "python.formatting.blackPath": "<absolute path to the black executable>",
    "[python]": {
        "editor.formatOnSave": true,
        "editor.rulers": [88], // Black enforces a line length of 88 characters.
    },
    ...
}