@meteorcloudy Now that this is green, could you trigger https://buildkite.com/bazel/bazel-at-head-plus-downstream for me on this PR so that I can see if something downstream breaks.

Hope that I did this right: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/5161#_

Hope that I did this right: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/5161#_

I think you triggered this job from master. You might want to cancel this job, not sure if it includes my changes.

I checked #26587 (comment) how we did it last time, and it looks like there is also https://buildkite.com/bazel/bcr-bazel-compatibility-test. Now I am not sure which one we need. And what to do exactly to trigger from this branch as both https://buildkite.com/bazel/bcr-bazel-compatibility-test/builds/492/steps/canvas and https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/4824/steps/canvas were executed from master and main last time 🤷

Maybe we have to wait for @meteorcloudy.

master is the base branch, but based on the errors this does include your commit. The BCR test is a separate check which runs on BCR modules rather than bazelbuild repos.

Added migration-ready to #10225 so that it will be tested in the nightly run of https://buildkite.com/bazel/bcr-bazel-compatibility-test/builds/722

Also manually triggered https://buildkite.com/bazel/bcr-bazel-compatibility-test/builds/723 with env vars

CI_RESOURCE_PERCENTAGE="10"
SELECT_TOP_BCR_MODULES="100"
SKIP_WAIT_FOR_APPROVAL="1"
USE_BAZELISK_MIGRATE="1"
USE_BAZEL_VERSION="latest"
INCOMPATIBLE_FLAGS="--incompatible_no_implicit_file_export"

We have some docs at https://github.com/bazelbuild/continuous-integration/tree/master/buildkite/bazel-central-registry#bcr-bazel-compatibility-test, @fmeum feel free to trigger a build when needed.

@meteorcloudy Could you trigger another run for https://buildkite.com/bazel/bcr-bazel-compatibility-test to verify that cgrindel/bazel-starlib#566 and bazel-contrib/rules_bazel_integration_test#552 are fixed.

bazelbuild/rules_kotlin#1440 and bazelbuild/rules_android#440 are still open (maintainers wanted to fix this or I am waiting on a PR review). Are these blockers for getting this flag flipped?

Speaking about blockers, is there anything we would have to change in this PR? E.g. waiting for the next rules_python release to clear out the TODOs added here?

You can already see the result in the nightly run: https://buildkite.com/bazel/bcr-bazel-compatibility-test/builds/785

Indeed bazel-starlib and rules_bazel_integration_test have been fixed, but rules_android and rules_multitool are broken by this flag.

I would say none of the broken modules should block the merge of this PR.

@hofbi Looks like we cannot flip this flag inside the google monorepo. Can you use https://cs.opensource.google/bazel/bazel/+/master:src/main/java/com/google/devtools/build/lib/packages/semantics/FlagConstants.java to refactor the change so that we only flip it for Bazel?

@meteorcloudy I added the flags constants as requested. Let me know if this works.

@meteorcloudy kind reminder

Sorry for the delay, this is in progress. FYI @deepalak56