flutter/packages needs a LUCI solution for check overrides

[stuartmorgan]

The version-check command in the flutter/packages CI is set up to, in presubmit, look for likely-missing version changes, as well as for major version changes to platform interface packages (since we almost never actually want to do those). Because it can have false positives, we need a way to override it when it's wrong—the idea is that this is something that we frequently forget (missing versions) or someone might not realize is a big deal (major version bumps to platform interfaces), so we want something that requires a human to explicitly say "yes, we looked at this, and we deliberately chose not to do what we are doing, rather than forgetting or not realizing".

How can we handle this in LUCI tests?

(The way it works with the Cirrus config is that one of the special env variables Cirrus passes to all runs is CIRRUS_PR_LABELS, which has the current set of GitHub labels on the PR, and so we set a label to indicate that we want to override, re-run that check, and the tooling knows to then not fail. We don't need it to be that specific flow, but we need some solution.)

[flutter-triage-bot]

Issue is assigned to multiple teams (infra, ecosystem). Please ensure the issue has only one team-* label at a time. Use fyi-* labels to have another team look at the issue without reassigning it.
The triaged-ecosystem label is irrelevant if there is no team-ecosystem label or fyi-ecosystem label.

[yusuf-goog]

I'm checking on this, but I don't think we have a way of passing information from the PR to the builds.

Would the characteristics of this requirement be satisfied by having a value set in the .ci.yaml file?

[stuartmorgan]

Would the characteristics of this requirement be satisfied by having a value set in the .ci.yaml file?

I'm not following; how would we override a check for one specific PR with .ci.yaml?

[stuartmorgan]

This is now the last dependency on Cirrus in flutter/packages.

[yusuf-goog]

@stuartmorgan change is in to propagate the labels to build properties, which you can use in your recipes.

[stuartmorgan]

which you can use in your recipes.

We just have the one recipe; could you update it to transfer that property to an environment variable? That would let us directly migrate the existing task.

[yusuf-goog]

Yes, I'll do that

[yusuf-goog]

https://flutter-review.googlesource.com/c/recipes/+/50421

[yusuf-goog]

Change submitted. closing.

[stuartmorgan]

This does not appear to be working. I made a test PR, verified that it failed as expected, then added an override label and re-ran the test. On the re-run, there environment variable is empty:
https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8771239673077318481/+/u/Run_package_tests/CHANGELOG_and_version_validation/execution_details

[yusuf-goog]

I think my change hasn't been pushed to prod yet, so its not appearing. tracking down the deployment.

[yusuf-goog]

Looks like flutter/cocoon#3032 blocking deployment of changes.

[stuartmorgan]

Thanks for tracking that down; I saw the variable being there and assumed that things had propagated, and didn't consider that just the recipe part could have.

Let me know when it's good to re-test!

[yusuf-goog]

Override labels now propagating: https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8771227551692090177/+/u/Run_package_tests/publishability/execution_details

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.