Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove the --all_incompatible_changes flag #13892

Closed
aiuto opened this issue Aug 23, 2021 · 3 comments
Closed

Remove the --all_incompatible_changes flag #13892

aiuto opened this issue Aug 23, 2021 · 3 comments
Assignees
Labels
P2 We'll consider working on this in future. (Assignee optional) team-Configurability platforms, toolchains, cquery, select(), config transitions type: process

Comments

@aiuto
Copy link
Contributor

aiuto commented Aug 23, 2021

The --all_incompatible_changes flag should be removed.

  • Its intent is not clear since the introduction of LTS tracks
    • It originally was used to gather all breaking changes for the next major release. The team does not do that any more since changes can be introduced at HEAD at any time
  • Sometimes distinct --incompatible_* flags can interfere with each other.
  • The mechanism does not capture Starlark defined flags. As we move flags out of the Bazel core and into Starlark it will become less useful.
@aiuto aiuto self-assigned this Aug 23, 2021
@aiuto aiuto changed the title Removed the --all_incompatible_changes flag Remove the --all_incompatible_changes flag Aug 23, 2021
@aiuto aiuto added P2 We'll consider working on this in future. (Assignee optional) team-Configurability platforms, toolchains, cquery, select(), config transitions labels Aug 23, 2021
@aiuto
Copy link
Contributor Author

aiuto commented Aug 23, 2021

Plan over several PRs:

  • Make it a no op
  • Remove from any Blaze and Bazel CI configurations
  • Delete the option Metadata tag TRIGGERED_BY_ALL_INCOMPATIBLE_CHANGES
  • Delete it
  • Clean up user test data that observes it

bazel-io pushed a commit that referenced this issue Aug 23, 2021
Step 1 of #13892

RELNOTES:
Disable --all_incompatible_changes flag.
PiperOrigin-RevId: 392476629
@brandjon
Copy link
Member

Has there been any decision on whether the extra expansion flag logic, which was added to the options parser expressly for the implementation of --all_incompatible_changes, should be deleted?

I feel like options parsing is enough of a mess that removing it won't necessarily make a dent in its complexity, absent a larger scale effort.

If it remains but is now unused, we should add a TODO to consider deprecating it.

@aiuto
Copy link
Contributor Author

aiuto commented Aug 30, 2021 via email

bazel-io pushed a commit that referenced this issue Aug 30, 2021
…unused.

Followup CLs:
- remove use of TRIGGERED_BY_ALL_INCOMPATIBLE_CHANGES in non-Bazel test data
- remove TRIGGERED_BY_ALL_INCOMPATIBLE_CHANGES from the remainder of Bazel
- remove --all_incompatible_changes from any CI specifications
- delete the option

See: #13892

RELNOTES: The --all_incompatible_changes flag is now a no-op
PiperOrigin-RevId: 393851730
tetromino added a commit to tetromino/bazel-website that referenced this issue Nov 11, 2021
…flag.

TRIGGERED_BY_ALL_INCOMPATIBLE_CHANGES was removed, see bazelbuild/bazel#13892
tetromino added a commit to bazelbuild/bazel-website that referenced this issue Nov 15, 2021
…flag (#334)

TRIGGERED_BY_ALL_INCOMPATIBLE_CHANGES was removed, see bazelbuild/bazel#13892

Meanwhile, incompatible-change is tag is required not just for stylistic reasons, but for the `bazelisk-plus-incompatible-flags` pipeline, see [`fetch_incompatible_flags` in bazelci.py](https://github.com/bazelbuild/continuous-integration/blob/master/buildkite/bazelci.py#L2713)
siddharthab pushed a commit to bazel-contrib/toolchains_llvm that referenced this issue Mar 8, 2022
As of bazel 5.0, --all_incompatible_changes flag is a no-op. So we
should switch to using bazelisk for checking any migration issues.

bazelbuild/bazel#13892

Because bazelisk does not allow specifying flag overrides on the command
line, we can not override the known failing incompatible flags, and so
our migration test will now fail. This is not ideal, but is the only
option going forward.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P2 We'll consider working on this in future. (Assignee optional) team-Configurability platforms, toolchains, cquery, select(), config transitions type: process
Projects
None yet
Development

No branches or pull requests

3 participants