commit 4e7c40b5dc765a626d6b9a7d5837d84d5b8990e2
author Chris Bracken <cbracken@google.com> Tue May 28 23:51:38 2024 +0000
committer CQ Bot Account <flutter-scoped@luci-project-accounts.iam.gserviceaccount.com> Tue May 28 23:51:38 2024 +0000
tree e084504070e6378870fc2d5ac62b6401e083d18c
parent c0610ba70baef1ab7f2cfa510d48840cec65c94a

Revert "Use git ref to determine release branch name"

This reverts commit c0610ba70baef1ab7f2cfa510d48840cec65c94a.

Reason for revert: The git rev-parse is operating on the ref but should be operating on the branch name. Sending a fixed version momentarily.

Original change's description:
> 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
> Change-Id: I8c8d6b8a3eb4fc69d78c0d04ecc63cd36a963297
> Reviewed-on: https://flutter-review.googlesource.com/c/recipes/+/57720
> Reviewed-by: Christopher Fujino <fujino@google.com>
> Reviewed-by: Zach Anderson <zra@google.com>
> Commit-Queue: Chris Bracken <cbracken@google.com>

TBR=zra@google.com,flutter-scoped@luci-project-accounts.iam.gserviceaccount.com,fujino@google.com,cbracken@google.com

Change-Id: Ie8477d744df4cd4e830fd9564d615d7e5a73edf5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: b/333426905
Reviewed-on: https://flutter-review.googlesource.com/c/recipes/+/57761
Reviewed-by: Chris Bracken <cbracken@google.com>
Reviewed-by: Christopher Fujino <fujino@google.com>
Commit-Queue: Christopher Fujino <fujino@google.com>
Commit-Queue: Chris Bracken <cbracken@google.com>