commit	883c67204b03caf7771c4ae3e7f7910c7adce2b1	[log] [tgz]
author	Oliver Newman <olivernewman@google.com>	Fri Sep 12 16:06:00 2025 -0700
committer	CQ Bot <fuchsia-internal-scoped@luci-project-accounts.iam.gserviceaccount.com>	Fri Sep 12 16:06:00 2025 -0700
tree	fadb12b5addbd182d72f2a6788cb30afe8a46cab
parent	429ff11b3e60963360fbb93f07318ce6fe571153 [diff]

[checkout] Use current_revision instead of current_revision_number

`current_revision_number` sometimes points to a revision that's not
actually the latest, if change details get retrieved shortly after a new
patchset gets uploaded. For example, here is the output of a change
details request for http://tqr/1038010, made exactly 1 second after
patchset 2 was uploaded: https://paste.googleplex.com/5742242425470976

Relevant parts:

    "current_revision": "aeb3c7415f2eef334cd5904e0f96e94826e1838c",
    "current_revision_number": 1,
    "revisions": {
      "7badc9b6881900ddf73c7ff1f219d26283150c3b": {
        "_number": 1,
        "commit": {
          "author": {},
          "committer": {}
        }
      },
      "aeb3c7415f2eef334cd5904e0f96e94826e1838c": {
        "_number": 2,
        "commit": {
          "author": {...},
          "committer": {...},
          "subject": "...",
          "message": "..."
        }
      }

Weirdly, the `current_revision` and `current_revision_number` fields
actually point to different revisions. I imagine this is due to some
sort of race condition in the Gerrit backend.

This is an issue because we use the `CURRENT_COMMIT` query option in the
request to get the full commit message for only the current revision and
not for any other revisions. Since the `current_revision_number` field
points to a non-latest revision, if we use that field to determine which
revision to use then we won't be able to get the message, which
currently causes an exception:
https://screenshot.googleplex.com/6K3qMVG7swZpQEV

As a workaround, use `current_revision` which seems to be more correct
and up-to-date.

Change-Id: I8218ba09f0d6b4ac3686b584ef3877d1dff66a24
Reviewed-on: https://fuchsia-review.googlesource.com/c/infra/recipes/+/1367416
Fuchsia-Auto-Submit: Oliver Newman <olivernewman@google.com>
Commit-Queue: Oliver Newman <olivernewman@google.com>
Reviewed-by: Jiaming Li <lijiaming@google.com>

57 files changed

tree: fadb12b5addbd182d72f2a6788cb30afe8a46cab

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.
    },
    ...
}