tree 7f0cc4a98008b088d34852833389f7749b7ea3ca
parent dbae015aefec506bac06b6571e74618637af00c2
author Chris Bracken <cbracken@google.com> 1716940658 +0000
committer CQ Bot Account <flutter-scoped@luci-project-accounts.iam.gserviceaccount.com> 1716940658 +0000

Revert "Use git ref to determine release branch name"

This reverts commit dbae015aefec506bac06b6571e74618637af00c2.

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.
>
> This is a cherry-pick of:
>   https://flutter-review.googlesource.com/c/recipes/+/57760
> to the flutter-3.18-candidate.18 branch.
>
> Bug: b/333426905
> Change-Id: Ia047351df2df08e919c4eb30391c88826ac4d546
> Reviewed-on: https://flutter-review.googlesource.com/c/recipes/+/57760
> Reviewed-by: Christopher Fujino <fujino@google.com>
> Commit-Queue: Chris Bracken <cbracken@google.com>

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

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