fix: move .scalafix.conf out to root#3888
Merged
Merged
Conversation
Contributor
There was a problem hiding this comment.
Copilot wasn't able to review any files in this pull request.
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
.scalafix.conf out to root
bobbai00
approved these changes
Oct 13, 2025
This was referenced May 2, 2026
Closed
Yicong-Huang
added a commit
that referenced
this pull request
May 2, 2026
…ks run (#4654) ### What changes were proposed in this PR? Close `.github/labeler.yml` gaps where root-level / workflow-adjacent config files matched no rule that maps to a CI stack: **Scala build / lint config → `service` label** (so the scala stack runs): - `build.sbt` (root) - `project/**` (sbt build sources, `plugins.sbt`) - `.scalafix.conf` (moved to root by #3888) - `.scalafmt.conf` Today these match either `**/build.sbt` (label `dependencies`, which `LABEL_STACKS` from #4640 maps to no-op) or no rule at all. A PR that only edits one of them skipped the scala stack — concrete example: PR #4649, labels `dependencies, fix, frontend, release/v1.1.0-incubating`, union `{frontend}`, no scala. `service` already maps to scala in `LABEL_STACKS`, so the union picks up scala automatically. **Workflow-adjacent / repo-wide config → `ci` label** (so the full matrix runs): - `.github/scripts/**` (CI helper scripts) - `.github/labeler.yml` (the labeler config itself) - `.asf.yaml` (branch protection rulesets, mailing list, GitHub features) These currently match no rule. `ci` already maps to all four stacks, which is the right gate for changes that can affect every stack. ### Any related issues, documentation, discussions? Closes #4653. ### How was this PR tested? This PR's own labeler run picks up `ci` (it edits `.github/labeler.yml`), so all stacks gate the change. After merge, future PRs that only edit a root scala build file pick up `service`, and PRs editing `.github/scripts/**`, `.github/labeler.yml`, or `.asf.yaml` pick up `ci`. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Opus 4.7
github-actions Bot
pushed a commit
that referenced
this pull request
May 2, 2026
…ks run (#4654) ### What changes were proposed in this PR? Close `.github/labeler.yml` gaps where root-level / workflow-adjacent config files matched no rule that maps to a CI stack: **Scala build / lint config → `service` label** (so the scala stack runs): - `build.sbt` (root) - `project/**` (sbt build sources, `plugins.sbt`) - `.scalafix.conf` (moved to root by #3888) - `.scalafmt.conf` Today these match either `**/build.sbt` (label `dependencies`, which `LABEL_STACKS` from #4640 maps to no-op) or no rule at all. A PR that only edits one of them skipped the scala stack — concrete example: PR #4649, labels `dependencies, fix, frontend, release/v1.1.0-incubating`, union `{frontend}`, no scala. `service` already maps to scala in `LABEL_STACKS`, so the union picks up scala automatically. **Workflow-adjacent / repo-wide config → `ci` label** (so the full matrix runs): - `.github/scripts/**` (CI helper scripts) - `.github/labeler.yml` (the labeler config itself) - `.asf.yaml` (branch protection rulesets, mailing list, GitHub features) These currently match no rule. `ci` already maps to all four stacks, which is the right gate for changes that can affect every stack. ### Any related issues, documentation, discussions? Closes #4653. ### How was this PR tested? This PR's own labeler run picks up `ci` (it edits `.github/labeler.yml`), so all stacks gate the change. After merge, future PRs that only edit a root scala build file pick up `service`, and PRs editing `.github/scripts/**`, `.github/labeler.yml`, or `.asf.yaml` pick up `ci`. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Opus 4.7 (backported from commit 5c7dac8)
SarahAsad23
pushed a commit
to madisonmlin/texera
that referenced
this pull request
May 20, 2026
yangzhang75
pushed a commit
to yangzhang75/texera
that referenced
this pull request
Jun 22, 2026
yangzhang75
pushed a commit
to yangzhang75/texera
that referenced
this pull request
Jun 22, 2026
…ks run (apache#4654) ### What changes were proposed in this PR? Close `.github/labeler.yml` gaps where root-level / workflow-adjacent config files matched no rule that maps to a CI stack: **Scala build / lint config → `service` label** (so the scala stack runs): - `build.sbt` (root) - `project/**` (sbt build sources, `plugins.sbt`) - `.scalafix.conf` (moved to root by apache#3888) - `.scalafmt.conf` Today these match either `**/build.sbt` (label `dependencies`, which `LABEL_STACKS` from apache#4640 maps to no-op) or no rule at all. A PR that only edits one of them skipped the scala stack — concrete example: PR apache#4649, labels `dependencies, fix, frontend, release/v1.1.0-incubating`, union `{frontend}`, no scala. `service` already maps to scala in `LABEL_STACKS`, so the union picks up scala automatically. **Workflow-adjacent / repo-wide config → `ci` label** (so the full matrix runs): - `.github/scripts/**` (CI helper scripts) - `.github/labeler.yml` (the labeler config itself) - `.asf.yaml` (branch protection rulesets, mailing list, GitHub features) These currently match no rule. `ci` already maps to all four stacks, which is the right gate for changes that can affect every stack. ### Any related issues, documentation, discussions? Closes apache#4653. ### How was this PR tested? This PR's own labeler run picks up `ci` (it edits `.github/labeler.yml`), so all stacks gate the change. After merge, future PRs that only edit a root scala build file pick up `service`, and PRs editing `.github/scripts/**`, `.github/labeler.yml`, or `.asf.yaml` pick up `ci`. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Opus 4.7
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
By default,
.scalafix.confshould be placed in project root. This PR fixes the issue, nowsbt scalafixAllcan execute properly by finding the correct rules.