feat(ci): gate stacks on a label-to-stacks map#4640
Merged
Conversation
Yicong-Huang
added
the
release/v1.1.0-incubating
Replace the ad-hoc cascade in required-checks.yml's precheck (skip
all on docs/dev only, skip frontend on no-frontend label, etc.)
with a static label -> required-stacks map. The run set is the
union of stacks across the PR's labels.
frontend -> { frontend }
python -> { scala, python } # pyamber drives scala integration tests
engine -> { scala, python } # amber/** spans both
service -> { scala, agent-service }
common -> { scala }
ddl-change -> { scala }
ci -> all stacks (workflow edits can affect anything)
Labels not in the map (docs, dev, dependencies, release/*, branch-
name labels) contribute no stacks. docs/dev-only or dependencies-
only PRs therefore emerge as empty union -> all stacks skipped,
without needing a special-case branch. dependencies is a no-op
because every dep manifest the labeler matches already sits under
a component directory and is covered by that component's label.
Push and workflow_dispatch events keep the existing all-true
default.
Closes apache#4639
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Yicong-Huang
force-pushed
the
feat/label-stacks-map
branch
from
08d791a to
182be00
Compare
This was referenced May 2, 2026
Yicong-Huang
pushed a commit
to Yicong-Huang/texera
that referenced
this pull request
May 2, 2026
The labeler's `service` rule used to match every '*-service/**' directory, which lumped agent-service (a TypeScript/Bun service) together with the scala backend services (access-control, config, file, computing-unit-managing, workflow-compiling) and pyright-language-service. With LABEL_STACKS introduced in apache#4640, that meant any agent-service-only PR also asked for the scala stack to run. Enumerate the scala-side services explicitly in `service` and add a dedicated `agent-service` label matching `agent-service/**`. Update LABEL_STACKS so: service -> { scala } agent-service -> { agent-service } Now an agent-service-only PR runs only the agent-service stack, not scala. PRs that touch both keep both labels and run both stacks via the existing union. Note: GitHub repo admins need to create the `agent-service` label in the repository before this lands; the labeler does not auto-create new labels. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Yicong-Huang
pushed a commit
to Yicong-Huang/texera
that referenced
this pull request
May 2, 2026
The labeler's `service` rule used to match every '*-service/**' directory, which lumped agent-service (a TypeScript/Bun service) together with the scala backend services (access-control, config, file, computing-unit-managing, workflow-compiling) and pyright-language-service. With LABEL_STACKS introduced in apache#4640, that meant any agent-service-only PR also asked for the scala stack to run. Enumerate the scala-side services explicitly in `service` and add a dedicated `agent-service` label matching `agent-service/**`. Update LABEL_STACKS so: service -> { scala } agent-service -> { agent-service } Now an agent-service-only PR runs only the agent-service stack, not scala. PRs that touch both keep both labels and run both stacks via the existing union. Note: GitHub repo admins need to create the `agent-service` label in the repository before this lands; the labeler does not auto-create new labels. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
github-actions Bot
pushed a commit
that referenced
this pull request
May 2, 2026
### What changes were proposed in this PR?
Replace the precheck's hand-written rule cascade in
`required-checks.yml` (skip all on `docs`/`dev` only, skip frontend if
no `frontend` label, …) with a static label → required-stacks map. The
run set is the union of stacks across the PR's current labels.
```js
const LABEL_STACKS = {
frontend: ["frontend"],
python: ["scala", "python"], // pyamber drives scala integration tests too
engine: ["scala", "python"], // amber/** spans both
service: ["scala", "agent-service"],
common: ["scala"],
"ddl-change":["scala"],
ci: ["frontend", "scala", "python", "agent-service"],
};
```
Per-label contribution to the run set (final stacks = union across all
PR labels):
| label | frontend | scala | python | agent-service |
|---|---|---|---|---|
| `frontend` | ✓ | | | |
| `python` | | ✓ | ✓ | |
| `engine` | | ✓ | ✓ | |
| `service` | | ✓ | | ✓ |
| `common` | | ✓ | | |
| `ddl-change` | | ✓ | | |
| `ci` | ✓ | ✓ | ✓ | ✓ |
| `docs` / `dev` / `dependencies` / `release/*` / branch-name | | | | |
Labels not in `LABEL_STACKS` (`docs`, `dev`, `dependencies`,
`release/*`, branch-name labels) contribute no stacks. `dependencies` is
intentionally a no-op: every dep manifest the labeler matches already
sits under a component directory and is covered by that component's
label (`frontend/package.json` → `frontend`, `*-service/build.sbt` →
`service`, `amber/{,operator-}requirements.txt` → `engine`).
Push and `workflow_dispatch` events keep the all-true default.
### Any related issues, documentation, discussions?
Closes #4639.
### How was this PR tested?
To be exercised by this PR's own run on CI: it touches
`.github/workflows/**`, which gives it the `ci` label, so every stack
should run. Removing `ci` (manually, for testing) and leaving only
`docs` should skip everything; adding `frontend` only should run only
the frontend stack.
### Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Opus 4.7
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
(backported from commit 382ebc2)
Yicong-Huang
pushed a commit
to Yicong-Huang/texera
that referenced
this pull request
May 2, 2026
The labeler's `service` rule used to match every '*-service/**' directory, which lumped agent-service (a TypeScript/Bun service) together with the scala backend services (access-control, config, file, computing-unit-managing, workflow-compiling) and pyright-language-service. With LABEL_STACKS introduced in apache#4640, that meant any agent-service-only PR also asked for the scala stack to run. Enumerate the scala-side services explicitly in `service` and add a dedicated `agent-service` label matching `agent-service/**`. Update LABEL_STACKS so: service -> { scala } agent-service -> { agent-service } Now an agent-service-only PR runs only the agent-service stack, not scala. PRs that touch both keep both labels and run both stacks via the existing union. Note: GitHub repo admins need to create the `agent-service` label in the repository before this lands; the labeler does not auto-create new labels. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Yicong-Huang
added a commit
that referenced
this pull request
May 2, 2026
### What changes were proposed in this PR? Split `agent-service` out of the broad `service` label so an agent-service-only PR runs only the agent-service stack, not scala. `.github/labeler.yml`: - `service` no longer matches `*-service/**`. It enumerates the scala-side service directories instead, because `actions/labeler@v6`'s `any-glob-to-any-file` does not exclude with negation patterns and the `all-globs-to-all-files: ['!agent-service/**']` workaround mishandles PRs that touch both agent-service and another service. - New `agent-service` label matches `agent-service/**`. `.github/workflows/required-checks.yml`: ```js service: ["scala"], // was ["scala", "agent-service"] "agent-service": ["agent-service"], // new ``` Updated decision table (bolded rows are this PR's diff vs #4640): | label | frontend | scala | python | agent-service | |---|---|---|---|---| | `frontend` | ✓ | | | | | `python` | | ✓ | ✓ | | | `engine` | | ✓ | ✓ | | | **`service`** | | **✓** | | ~~✓~~ | | **`agent-service`** (new) | | | | **✓** | | `common` | | ✓ | | | | `ddl-change` | | ✓ | | | | `ci` | ✓ | ✓ | ✓ | ✓ | | `docs` / `dev` / `dependencies` / `release/*` / branch-name | | | | | PRs touching both directories keep both labels and run both stacks via the union. ### Any related issues, documentation, discussions? Closes #4642. ### How was this PR tested? This PR's own run will exercise it: it touches `.github/workflows/**` and `.github/labeler.yml`, so the labeler will add `ci`, which fans out to every stack. After merge, an agent-service-only change should land only the `agent-service` label and run only the agent-service stack. ### 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
### What changes were proposed in this PR? Split `agent-service` out of the broad `service` label so an agent-service-only PR runs only the agent-service stack, not scala. `.github/labeler.yml`: - `service` no longer matches `*-service/**`. It enumerates the scala-side service directories instead, because `actions/labeler@v6`'s `any-glob-to-any-file` does not exclude with negation patterns and the `all-globs-to-all-files: ['!agent-service/**']` workaround mishandles PRs that touch both agent-service and another service. - New `agent-service` label matches `agent-service/**`. `.github/workflows/required-checks.yml`: ```js service: ["scala"], // was ["scala", "agent-service"] "agent-service": ["agent-service"], // new ``` Updated decision table (bolded rows are this PR's diff vs #4640): | label | frontend | scala | python | agent-service | |---|---|---|---|---| | `frontend` | ✓ | | | | | `python` | | ✓ | ✓ | | | `engine` | | ✓ | ✓ | | | **`service`** | | **✓** | | ~~✓~~ | | **`agent-service`** (new) | | | | **✓** | | `common` | | ✓ | | | | `ddl-change` | | ✓ | | | | `ci` | ✓ | ✓ | ✓ | ✓ | | `docs` / `dev` / `dependencies` / `release/*` / branch-name | | | | | PRs touching both directories keep both labels and run both stacks via the union. ### Any related issues, documentation, discussions? Closes #4642. ### How was this PR tested? This PR's own run will exercise it: it touches `.github/workflows/**` and `.github/labeler.yml`, so the labeler will add `ci`, which fans out to every stack. After merge, an agent-service-only change should land only the `agent-service` label and run only the agent-service stack. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Opus 4.7 (backported from commit 04a1059)
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)
Yicong-Huang
added a commit
that referenced
this pull request
May 2, 2026
## What changes were proposed in this PR? - `.github/workflows/build.yml`: - Replace the `scala` job with `amber`. It runs the cross-cutting Scala lints (`scalafmtCheckAll`, `scalafixAll --check`) once on behalf of every Scala module, builds `WorkflowExecutionService/dist`, license-checks the amber dist against `amber/LICENSE-binary-java`, and runs amber tests via `WorkflowExecutionService/jacoco`. - New `platform` job: a `strategy.matrix.include` over the five non-amber Scala services (config-service, access-control-service, file-service, computing-unit-managing-service, workflow-compiling-service). Each entry runs `sbt "<Service>/dist" "<Service>/test"` and license-checks its own dist `lib/` against `<service>/LICENSE-binary` in isolation. This is now possible because per-module LICENSE-binary files were introduced in #4668. - `run_scala` input replaced by `run_amber` + `run_platform`. - `.github/labeler.yml`: - New `platform` label for the five platform service dirs. - `service` label removed. The two things it carried go elsewhere: `pyright-language-service/**` is left uncategorized (no test stack today), and the root-level Scala build/lint config (`build.sbt`, `project/**`, `.scalafix.conf`, `.scalafmt.conf`) joins the `common` glob — `common` already maps to amber + platform, which is correct for changes that affect every Scala module. - `.github/workflows/required-checks.yml`: - Precheck now emits `run_amber` + `run_platform` instead of `run_scala`. - LABEL_STACKS routes the new label set. Build and backport callers pass the new inputs through. ### Label → stack matrix | Label | frontend | amber | platform | python | agent-service | |---|:-:|:-:|:-:|:-:|:-:| | `frontend` | ✓ | | | | | | `engine` | | ✓ | | ✓ | | | `python` | | ✓ | | ✓ | | | `platform` | | | ✓ | | | | `common` | | ✓ | ✓ | | | | `ddl-change` | | ✓ | ✓ | | | | `agent-service` | | | | | ✓ | | `ci` | ✓ | ✓ | ✓ | ✓ | ✓ | | `docs`, `dev`, `dependencies`, `feature`, `fix`, `refactor`, `release/*` | | | | | | The selected stacks are the union across all PR labels. PRs that pick up only no-stack labels (e.g. docs-only, dev-only) skip every build stack. Push and `workflow_dispatch` events run every stack unconditionally. ### Why per-service license check is now possible Before #4668 there was a single repo-wide `LICENSE-binary` covering the union of all service jars. Splitting the license check per service would have made every per-service check fail — each lib is a strict subset of the union, so the script would report STALE jars (claimed in the union, not in this service). #4668 ships per-module `LICENSE-binary` files at the repo root (`config-service/LICENSE-binary`, `amber/LICENSE-binary-java`, etc.), so each service's dist `lib/` is now validated against its own ground-truth file via `check_binary_deps.py --license-binary <module>/LICENSE-binary`. ## Any related issues, documentation, discussions? Closes #4631. Builds on #4668 (per-module LICENSE-binary files) and #4640 (LABEL_STACKS gating). ## How was this PR tested? YAML parses locally for all three modified files. Currently exercising on this PR's CI run: amber job runs unconditionally; platform matrix runs because the `platform` and `ci` labels are present. ## Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Opus 4.7 (Claude Code)
Yicong-Huang
added a commit
that referenced
this pull request
May 2, 2026
## What changes were proposed in this PR? - `.github/workflows/build.yml`: - Replace the `scala` job with `amber`. It runs the cross-cutting Scala lints (`scalafmtCheckAll`, `scalafixAll --check`) once on behalf of every Scala module, builds `WorkflowExecutionService/dist`, license-checks the amber dist against `amber/LICENSE-binary-java`, and runs amber tests via `WorkflowExecutionService/jacoco`. - New `platform` job: a `strategy.matrix.include` over the five non-amber Scala services (config-service, access-control-service, file-service, computing-unit-managing-service, workflow-compiling-service). Each entry runs `sbt "<Service>/dist" "<Service>/test"` and license-checks its own dist `lib/` against `<service>/LICENSE-binary` in isolation. This is now possible because per-module LICENSE-binary files were introduced in #4668. - `run_scala` input replaced by `run_amber` + `run_platform`. - `.github/labeler.yml`: - New `platform` label for the five platform service dirs. - `service` label removed. The two things it carried go elsewhere: `pyright-language-service/**` is left uncategorized (no test stack today), and the root-level Scala build/lint config (`build.sbt`, `project/**`, `.scalafix.conf`, `.scalafmt.conf`) joins the `common` glob — `common` already maps to amber + platform, which is correct for changes that affect every Scala module. - `.github/workflows/required-checks.yml`: - Precheck now emits `run_amber` + `run_platform` instead of `run_scala`. - LABEL_STACKS routes the new label set. Build and backport callers pass the new inputs through. ### Label → stack matrix | Label | frontend | amber | platform | python | agent-service | |---|:-:|:-:|:-:|:-:|:-:| | `frontend` | ✓ | | | | | | `engine` | | ✓ | | ✓ | | | `python` | | ✓ | | ✓ | | | `platform` | | | ✓ | | | | `common` | | ✓ | ✓ | | | | `ddl-change` | | ✓ | ✓ | | | | `agent-service` | | | | | ✓ | | `ci` | ✓ | ✓ | ✓ | ✓ | ✓ | | `docs`, `dev`, `dependencies`, `feature`, `fix`, `refactor`, `release/*` | | | | | | The selected stacks are the union across all PR labels. PRs that pick up only no-stack labels (e.g. docs-only, dev-only) skip every build stack. Push and `workflow_dispatch` events run every stack unconditionally. ### Why per-service license check is now possible Before #4668 there was a single repo-wide `LICENSE-binary` covering the union of all service jars. Splitting the license check per service would have made every per-service check fail — each lib is a strict subset of the union, so the script would report STALE jars (claimed in the union, not in this service). #4668 ships per-module `LICENSE-binary` files at the repo root (`config-service/LICENSE-binary`, `amber/LICENSE-binary-java`, etc.), so each service's dist `lib/` is now validated against its own ground-truth file via `check_binary_deps.py --license-binary <module>/LICENSE-binary`. ## Any related issues, documentation, discussions? Closes #4631. Builds on #4668 (per-module LICENSE-binary files) and #4640 (LABEL_STACKS gating). ## How was this PR tested? YAML parses locally for all three modified files. Currently exercising on this PR's CI run: amber job runs unconditionally; platform matrix runs because the `platform` and `ci` labels are present. ## Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Opus 4.7 (Claude Code) (backported from commit 6cf4322)
SarahAsad23
pushed a commit
to SarahAsad23/texera
that referenced
this pull request
May 4, 2026
### What changes were proposed in this PR?
Replace the precheck's hand-written rule cascade in
`required-checks.yml` (skip all on `docs`/`dev` only, skip frontend if
no `frontend` label, …) with a static label → required-stacks map. The
run set is the union of stacks across the PR's current labels.
```js
const LABEL_STACKS = {
frontend: ["frontend"],
python: ["scala", "python"], // pyamber drives scala integration tests too
engine: ["scala", "python"], // amber/** spans both
service: ["scala", "agent-service"],
common: ["scala"],
"ddl-change":["scala"],
ci: ["frontend", "scala", "python", "agent-service"],
};
```
Per-label contribution to the run set (final stacks = union across all
PR labels):
| label | frontend | scala | python | agent-service |
|---|---|---|---|---|
| `frontend` | ✓ | | | |
| `python` | | ✓ | ✓ | |
| `engine` | | ✓ | ✓ | |
| `service` | | ✓ | | ✓ |
| `common` | | ✓ | | |
| `ddl-change` | | ✓ | | |
| `ci` | ✓ | ✓ | ✓ | ✓ |
| `docs` / `dev` / `dependencies` / `release/*` / branch-name | | | | |
Labels not in `LABEL_STACKS` (`docs`, `dev`, `dependencies`,
`release/*`, branch-name labels) contribute no stacks. `dependencies` is
intentionally a no-op: every dep manifest the labeler matches already
sits under a component directory and is covered by that component's
label (`frontend/package.json` → `frontend`, `*-service/build.sbt` →
`service`, `amber/{,operator-}requirements.txt` → `engine`).
Push and `workflow_dispatch` events keep the all-true default.
### Any related issues, documentation, discussions?
Closes apache#4639.
### How was this PR tested?
To be exercised by this PR's own run on CI: it touches
`.github/workflows/**`, which gives it the `ci` label, so every stack
should run. Removing `ci` (manually, for testing) and leaving only
`docs` should skip everything; adding `frontend` only should run only
the frontend stack.
### Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Opus 4.7
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
SarahAsad23
pushed a commit
to SarahAsad23/texera
that referenced
this pull request
May 4, 2026
### What changes were proposed in this PR? Split `agent-service` out of the broad `service` label so an agent-service-only PR runs only the agent-service stack, not scala. `.github/labeler.yml`: - `service` no longer matches `*-service/**`. It enumerates the scala-side service directories instead, because `actions/labeler@v6`'s `any-glob-to-any-file` does not exclude with negation patterns and the `all-globs-to-all-files: ['!agent-service/**']` workaround mishandles PRs that touch both agent-service and another service. - New `agent-service` label matches `agent-service/**`. `.github/workflows/required-checks.yml`: ```js service: ["scala"], // was ["scala", "agent-service"] "agent-service": ["agent-service"], // new ``` Updated decision table (bolded rows are this PR's diff vs apache#4640): | label | frontend | scala | python | agent-service | |---|---|---|---|---| | `frontend` | ✓ | | | | | `python` | | ✓ | ✓ | | | `engine` | | ✓ | ✓ | | | **`service`** | | **✓** | | ~~✓~~ | | **`agent-service`** (new) | | | | **✓** | | `common` | | ✓ | | | | `ddl-change` | | ✓ | | | | `ci` | ✓ | ✓ | ✓ | ✓ | | `docs` / `dev` / `dependencies` / `release/*` / branch-name | | | | | PRs touching both directories keep both labels and run both stacks via the union. ### Any related issues, documentation, discussions? Closes apache#4642. ### How was this PR tested? This PR's own run will exercise it: it touches `.github/workflows/**` and `.github/labeler.yml`, so the labeler will add `ci`, which fans out to every stack. After merge, an agent-service-only change should land only the `agent-service` label and run only the agent-service stack. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Opus 4.7
yangzhang75
pushed a commit
to yangzhang75/texera
that referenced
this pull request
Jun 22, 2026
### What changes were proposed in this PR?
Replace the precheck's hand-written rule cascade in
`required-checks.yml` (skip all on `docs`/`dev` only, skip frontend if
no `frontend` label, …) with a static label → required-stacks map. The
run set is the union of stacks across the PR's current labels.
```js
const LABEL_STACKS = {
frontend: ["frontend"],
python: ["scala", "python"], // pyamber drives scala integration tests too
engine: ["scala", "python"], // amber/** spans both
service: ["scala", "agent-service"],
common: ["scala"],
"ddl-change":["scala"],
ci: ["frontend", "scala", "python", "agent-service"],
};
```
Per-label contribution to the run set (final stacks = union across all
PR labels):
| label | frontend | scala | python | agent-service |
|---|---|---|---|---|
| `frontend` | ✓ | | | |
| `python` | | ✓ | ✓ | |
| `engine` | | ✓ | ✓ | |
| `service` | | ✓ | | ✓ |
| `common` | | ✓ | | |
| `ddl-change` | | ✓ | | |
| `ci` | ✓ | ✓ | ✓ | ✓ |
| `docs` / `dev` / `dependencies` / `release/*` / branch-name | | | | |
Labels not in `LABEL_STACKS` (`docs`, `dev`, `dependencies`,
`release/*`, branch-name labels) contribute no stacks. `dependencies` is
intentionally a no-op: every dep manifest the labeler matches already
sits under a component directory and is covered by that component's
label (`frontend/package.json` → `frontend`, `*-service/build.sbt` →
`service`, `amber/{,operator-}requirements.txt` → `engine`).
Push and `workflow_dispatch` events keep the all-true default.
### Any related issues, documentation, discussions?
Closes apache#4639.
### How was this PR tested?
To be exercised by this PR's own run on CI: it touches
`.github/workflows/**`, which gives it the `ci` label, so every stack
should run. Removing `ci` (manually, for testing) and leaving only
`docs` should skip everything; adding `frontend` only should run only
the frontend stack.
### Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Opus 4.7
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
yangzhang75
pushed a commit
to yangzhang75/texera
that referenced
this pull request
Jun 22, 2026
### What changes were proposed in this PR? Split `agent-service` out of the broad `service` label so an agent-service-only PR runs only the agent-service stack, not scala. `.github/labeler.yml`: - `service` no longer matches `*-service/**`. It enumerates the scala-side service directories instead, because `actions/labeler@v6`'s `any-glob-to-any-file` does not exclude with negation patterns and the `all-globs-to-all-files: ['!agent-service/**']` workaround mishandles PRs that touch both agent-service and another service. - New `agent-service` label matches `agent-service/**`. `.github/workflows/required-checks.yml`: ```js service: ["scala"], // was ["scala", "agent-service"] "agent-service": ["agent-service"], // new ``` Updated decision table (bolded rows are this PR's diff vs apache#4640): | label | frontend | scala | python | agent-service | |---|---|---|---|---| | `frontend` | ✓ | | | | | `python` | | ✓ | ✓ | | | `engine` | | ✓ | ✓ | | | **`service`** | | **✓** | | ~~✓~~ | | **`agent-service`** (new) | | | | **✓** | | `common` | | ✓ | | | | `ddl-change` | | ✓ | | | | `ci` | ✓ | ✓ | ✓ | ✓ | | `docs` / `dev` / `dependencies` / `release/*` / branch-name | | | | | PRs touching both directories keep both labels and run both stacks via the union. ### Any related issues, documentation, discussions? Closes apache#4642. ### How was this PR tested? This PR's own run will exercise it: it touches `.github/workflows/**` and `.github/labeler.yml`, so the labeler will add `ci`, which fans out to every stack. After merge, an agent-service-only change should land only the `agent-service` label and run only the agent-service stack. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Opus 4.7
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
yangzhang75
pushed a commit
to yangzhang75/texera
that referenced
this pull request
Jun 22, 2026
## What changes were proposed in this PR? - `.github/workflows/build.yml`: - Replace the `scala` job with `amber`. It runs the cross-cutting Scala lints (`scalafmtCheckAll`, `scalafixAll --check`) once on behalf of every Scala module, builds `WorkflowExecutionService/dist`, license-checks the amber dist against `amber/LICENSE-binary-java`, and runs amber tests via `WorkflowExecutionService/jacoco`. - New `platform` job: a `strategy.matrix.include` over the five non-amber Scala services (config-service, access-control-service, file-service, computing-unit-managing-service, workflow-compiling-service). Each entry runs `sbt "<Service>/dist" "<Service>/test"` and license-checks its own dist `lib/` against `<service>/LICENSE-binary` in isolation. This is now possible because per-module LICENSE-binary files were introduced in apache#4668. - `run_scala` input replaced by `run_amber` + `run_platform`. - `.github/labeler.yml`: - New `platform` label for the five platform service dirs. - `service` label removed. The two things it carried go elsewhere: `pyright-language-service/**` is left uncategorized (no test stack today), and the root-level Scala build/lint config (`build.sbt`, `project/**`, `.scalafix.conf`, `.scalafmt.conf`) joins the `common` glob — `common` already maps to amber + platform, which is correct for changes that affect every Scala module. - `.github/workflows/required-checks.yml`: - Precheck now emits `run_amber` + `run_platform` instead of `run_scala`. - LABEL_STACKS routes the new label set. Build and backport callers pass the new inputs through. ### Label → stack matrix | Label | frontend | amber | platform | python | agent-service | |---|:-:|:-:|:-:|:-:|:-:| | `frontend` | ✓ | | | | | | `engine` | | ✓ | | ✓ | | | `python` | | ✓ | | ✓ | | | `platform` | | | ✓ | | | | `common` | | ✓ | ✓ | | | | `ddl-change` | | ✓ | ✓ | | | | `agent-service` | | | | | ✓ | | `ci` | ✓ | ✓ | ✓ | ✓ | ✓ | | `docs`, `dev`, `dependencies`, `feature`, `fix`, `refactor`, `release/*` | | | | | | The selected stacks are the union across all PR labels. PRs that pick up only no-stack labels (e.g. docs-only, dev-only) skip every build stack. Push and `workflow_dispatch` events run every stack unconditionally. ### Why per-service license check is now possible Before apache#4668 there was a single repo-wide `LICENSE-binary` covering the union of all service jars. Splitting the license check per service would have made every per-service check fail — each lib is a strict subset of the union, so the script would report STALE jars (claimed in the union, not in this service). apache#4668 ships per-module `LICENSE-binary` files at the repo root (`config-service/LICENSE-binary`, `amber/LICENSE-binary-java`, etc.), so each service's dist `lib/` is now validated against its own ground-truth file via `check_binary_deps.py --license-binary <module>/LICENSE-binary`. ## Any related issues, documentation, discussions? Closes apache#4631. Builds on apache#4668 (per-module LICENSE-binary files) and apache#4640 (LABEL_STACKS gating). ## How was this PR tested? YAML parses locally for all three modified files. Currently exercising on this PR's CI run: amber job runs unconditionally; platform matrix runs because the `platform` and `ci` labels are present. ## Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Opus 4.7 (Claude Code)
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
2 participants
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.
What changes were proposed in this PR?
Replace the precheck's hand-written rule cascade in
required-checks.yml(skip all ondocs/devonly, skip frontend if nofrontendlabel, …) with a static label → required-stacks map. The run set is the union of stacks across the PR's current labels.Per-label contribution to the run set (final stacks = union across all PR labels):
frontendpythonengineservicecommonddl-changecidocs/dev/dependencies/release/*/ branch-nameLabels not in
LABEL_STACKS(docs,dev,dependencies,release/*, branch-name labels) contribute no stacks.dependenciesis intentionally a no-op: every dep manifest the labeler matches already sits under a component directory and is covered by that component's label (frontend/package.json→frontend,*-service/build.sbt→service,amber/{,operator-}requirements.txt→engine).Push and
workflow_dispatchevents keep the all-true default.Any related issues, documentation, discussions?
Closes #4639.
How was this PR tested?
To be exercised by this PR's own run on CI: it touches
.github/workflows/**, which gives it thecilabel, so every stack should run. Removingci(manually, for testing) and leaving onlydocsshould skip everything; addingfrontendonly should run only the frontend stack.Was this PR authored or co-authored using generative AI tooling?
Generated-by: Claude Opus 4.7