Reapply "Use git ref to determine release branch name"

This updates the RepoUtils `release_candidate_branch` function to make
use of the incoming git ref, if specified, when looking up which release
candidate branch corresponds to the commit at HEAD.

The previous implementation returned the first branch starting with
"flutter-" that happens to contain the checked out commit SHA. This is
problematic for two reasons:

  * Multiple branches may contain the checked out SHA. In particular, if
    newer release branches have been created since the release at which
    we're building, it's likely they all contain the commit. Previously,
    in that case, we would arbitrarily return the first matching branch.
    Assuming the branches are returned in lexicographic order (probably
    not a safe assumption), older branches will appear earlier in the
    list, meaning we're more likely to select the wrong branch.

  * We're not actually interested in whether a branch *contains* the
    commit at HEAD; we're interested in knowing if the branch has the
    commit at HEAD as *its* HEAD commit.

This updates the function to check that a git ref starting with
"flutter-" is specified and that its HEAD matches the current HEAD
commit.

Background
==========

After renewing and uploading the iOS/macOS signing certificates (a
process required once every 5 years), we triggered a release build to
test that the new certs were picked up. This generated:

* Top-level release/release_builder build 618:
  https://ci.chromium.org/ui/p/dart-internal/builders/flutter/Mac%20engine_release_builder/618/overview

* Which triggered a macOS engine_v2/engine_v2 build 12070:
  https://ci.chromium.org/ui/p/dart-internal/builders/flutter/Mac%20Production%20Engine%20Drone/12070/overview

* Which generated this macOS host_debug engine_v2/builder build 12082:
  https://ci.chromium.org/ui/p/dart-internal/builders/flutter/Mac%20Production%20Engine%20Drone/12082/infra

Looking at the setup_build/run_recipe output for the top level build
(618) we see the correct release candidate ref passed in:
refs/heads/flutter-3.18-candidate.18

We see the same release candidate ref in the setup_build/run_recipe
output for the macOS engine_v2/engine_v2 build (12070).

However, looking at the third-level macOS host_debug engine_v2/builder
build, we see the wrong candidate branch is selected in the
kitchen-checkout and exe sections of the recipe_engine/buildbucket
mappings: refs/heads/flutter-0.0-candidate.1234

This is due to the flaw in the previous branch selection logic described above.

Bug: b/333426905

This reverts commit 4e7c40b5dc765a626d6b9a7d5837d84d5b8990e2.

Change-Id: If252e32b834d4239534eaa55482bc3c98e65c90b
Reviewed-on: https://flutter-review.googlesource.com/c/recipes/+/57780
Commit-Queue: Chris Bracken <cbracken@google.com>
Reviewed-by: Christopher Fujino <fujino@google.com>
37 files changed
tree: ee89629280fa3f9c9f75072feda41801f7de0964
  1. infra/
  2. recipe_modules/
  3. recipes/
  4. .gitignore
  5. .style.yapf
  6. AUTHORS
  7. CONTRIBUTING.md
  8. LICENSE
  9. OWNERS
  10. README.md
  11. recipes.py
README.md

Flutter LUCI Recipes

This repository contains Flutter's LUCI recipes. For the LUCI infrastructure config, see flutter/infra. Builds can be found in the Flutter Dashboard.

Supported repositories roll their .ci.yaml into flutter/infra, which updates what properties builds have. For example, flutter config specifies various dependencies the different tests require, which are then used by the flutter_deps recipe_module No modifications to flutter/infra are required to work on the recipes.

Contributing

Please follow instructions on Contributing docs to set up your development environment.