Use new buildkite pipeline names

.github/ISSUE_TEMPLATE/07-ci-flake.yml

@@ -25,7 +25,7 @@ body:
       label: Buildkite link
       description: |
         Provide a link to the failed Buildkite job.
-      placeholder: https://buildkite.com/materialize/tests/builds/...
+      placeholder: https://buildkite.com/materialize/test/builds/...
     validations:
       required: true
   - type: textarea

README.md

@@ -1,4 +1,4 @@
-[![Build status](https://badge.buildkite.com/97d6604e015bf633d1c2a12d166bb46f3b43a927d3952c999a.svg?branch=main)](https://buildkite.com/materialize/tests)
+[![Build status](https://badge.buildkite.com/97d6604e015bf633d1c2a12d166bb46f3b43a927d3952c999a.svg?branch=main)](https://buildkite.com/materialize/test)
 [![Doc reference](https://img.shields.io/badge/doc-reference-orange)](https://materialize.com/docs)
 [![Chat on Slack](https://img.shields.io/badge/chat-on%20slack-purple)](https://materialize.com/s/chat)
 

ci/deploy/pipeline.template.yml

@@ -38,7 +38,7 @@ steps:
       queue: linux-x86_64
 
   - label: ":bulb: Full SQL Logic Tests"
-    trigger: sql-logic-tests
+    trigger: slt
     async: true
     branches: "v*.*rc*"
     build:
@@ -48,7 +48,7 @@ steps:
         BUILDKITE_TAG: "$BUILDKITE_TAG"
 
   - label: ":nightmare: Full Nightly"
-    trigger: nightlies
+    trigger: nightly
     async: true
     branches: "v*.*rc*"
     build:

ci/mkpipeline.py

@@ -326,8 +326,8 @@ def check_depends_on(pipeline: Any, pipeline_name: str) -> None:
 def add_version_to_preflight_tests(pipeline: Any) -> None:
     for step in steps(pipeline):
         if step.get("id", "") in (
-            "tests-preflight-check-rollback",
-            "nightlies-preflight-check-rollback",
+            "test-preflight-check-rollback",
+            "nightly-preflight-check-rollback",
         ):
             current_version = MzVersion.parse_cargo()
             version = get_previous_published_version(

ci/release-qualification/pipeline.template.yml

@@ -168,22 +168,22 @@ steps:
             args: [--max-joins=15, --explain-only, --runtime=6000]
       skip: "Reenable when #23451 is fixed"
 
-  - id: tests-preflight-check-rollback
-    label: Tests with preflight check and rollback
+  - id: test-preflight-check-rollback
+    label: Test with preflight check and rollback
     depends_on: []
     skip: "TODO(def-): Too complex to adapt for all mzcompose-based tests"
-    trigger: tests
+    trigger: test
     async: false
     build:
       env:
         CI_FINAL_PREFLIGHT_CHECK_VERSION: "${BUILDKITE_TAG}"
         CI_FINAL_PREFLIGHT_CHECK_ROLLBACK: 1
 
-  - id: nightlies-preflight-check-rollback
-    label: Nightlies with preflight check and rollback
+  - id: nightly-preflight-check-rollback
+    label: Nightly with preflight check and rollback
     depends_on: []
     skip: "TODO(def-): Too complex to adapt for all mzcompose-based tests"
-    trigger: nightlies
+    trigger: nightly
     async: false
     build:
       env:

ci/test/pipeline.template.yml

@@ -669,7 +669,7 @@ steps:
   - id: nightly-if-release
     label: Nightly for releases
     depends_on: devel-docker-tags
-    trigger: nightlies
+    trigger: nightly
     async: true
     build:
       commit: "$BUILDKITE_COMMIT"
@@ -684,7 +684,7 @@ steps:
     label: Nightly for risky PRs
     skip: "Temporary disabled until a cost/beneft analysis"
     depends_on: devel-docker-tags
-    trigger: nightlies
+    trigger: nightly
     async: true
     build:
       commit: "$BUILDKITE_COMMIT"

doc/developer/101-query-compilation.md

@@ -95,7 +95,7 @@ Currently, the optimization team is mostly concerned with the `HIR ⇒ MIR` and
     * A PR can be merged if it passes Fast SLT.
     * A PR does not need to pass Full SLT tests (`test/sqllogictest/sqlite`) to be merged.
         * Full SLT tests take 2-3 hours.
-        * You can manually initiate full SLT tests on your branch [here](https://buildkite.com/materialize/sql-logic-tests).
+        * You can manually initiate full SLT tests on your branch [here](https://buildkite.com/materialize/slt).
 * [Testdrive](https://github.com/MaterializeInc/materialize/blob/main/doc/developer/testdrive.md)
     * We generally do not use testdrive except to see [linear operators in action](https://github.com/MaterializeInc/materialize/blob/main/test/testdrive/source-linear-operators.td).
 

doc/developer/code-coverage.md

@@ -26,7 +26,7 @@ Additionally you can also download the full coverage report in HTML format from
 
 ## Limitations
 
-The [Coverage](https://buildkite.com/materialize/coverage/builds) Buildkite pipeline runs a subset of tests from the [Tests](https://buildkite.com/materialize/tests) pipeline, which is already automatically run against each pull request. The excluded tests are marked with a `coverage: skip` in the [`pipeline.template.yml`](https://github.com/MaterializeInc/materialize/blob/main/ci/test/pipeline.template.yml):
+The [Coverage](https://buildkite.com/materialize/coverage/builds) Buildkite pipeline runs a subset of tests from the [Test](https://buildkite.com/materialize/test) pipeline, which is already automatically run against each pull request. The excluded tests are marked with a `coverage: skip` in the [`pipeline.template.yml`](https://github.com/MaterializeInc/materialize/blob/main/ci/test/pipeline.template.yml):
 
 - Miri test: Subset of cargo test, no additional use
 - Maelstrom coverage of persist: Randomized testing probably shouldn't count for coverage, not stable

doc/developer/design/20230223_stabilize_with_mutually_recursive.md

@@ -207,7 +207,7 @@ We can invest time proportional to the complexity of the transform to ensure tha
 
 1. **Integration tests.**
 We will add test scenarios inspired by the use cases of our prospects as end-to-end `*.slt` tests.
-We will also add at least one long-running `mzcompose` test runs [as part of our nightly tests](https://buildkite.com/materialize/nightlies) and is used when qualifying future releases.
+We will also add at least one long-running `mzcompose` test runs [as part of our nightly tests](https://buildkite.com/materialize/nightly) and is used when qualifying future releases.
 As those tests will include expected results, it will be great if we have a reference external iteration driver for the semantics proposed in the original design doc[^wmr].
 That way we can cross-check the results of the reference and the internal implementation of WMR support and ensure that both produce equal results.
 We can implement such driver in Python and integrate it in our `mzcompose` tests.

doc/developer/design/20230421_stabilize_monotonic_select.md

@@ -133,7 +133,7 @@ Among the work items to stabilize monotonic one-shot `SELECT`s, this is the leas
 
 As mentioned previously, the feature is now gated behind the flag `enable_monotonic_oneshot_selects`. The proposals in this document assume that we would like to eventually retire this feature flag. Based on this observation, the following lifecycle is proposed:
 
-* Once MaterializeInc/materialize#18734 is tackled, we can let the feature be continuously tested in CI and nightlies during at least 2 weeks.
+* Once MaterializeInc/materialize#18734 is tackled, we can let the feature be continuously tested in CI and nightly during at least 2 weeks.
 * Given the work in MaterializeInc/materialize#19223, we can enable the flag in staging once initial validation through testing succeeds. Ideally, we should let people experiment with the feature in staging for 1-2 weeks. Note that a full solution to MaterializeInc/materialize#18089 would be ideal to eliminate confusion regarding `EXPLAIN` behavior and make the feature more understandable to customers in production.
 * We consider solutions to MaterializeInc/materialize#18732 and MaterializeInc/materialize#18890 as highly desirable work items that bring about performance improvements for this feature. We can consider these improvements, however, optional wrt. enablement of the feature in staging. It would be ideal to tackle at a minimum MaterializeInc/materialize#18890 before enabling the feature in production, as we observed potential regressions in simple plans (e.g., for `MIN`/`MAX` over an entire collection) that would be ameliorated by a fix. If any of these fixes lands after the observation period for the previous two bullet points, we propose an additional 1 week of observation in staging and CI for derisking.
 * Once the feature is enabled in production, we can monitor for 1-2 weeks, and then plan the retirement of the feature flag in the next release cycle.

doc/developer/feature-benchmark.md

@@ -59,7 +59,7 @@ interference of any defaults that may be in effect and that can change over time
 
 ## Running manually in Buildkite
 
-Go to the [Buildkite Nightly Job](https://buildkite.com/materialize/nightlies), click the down arrow button
+Go to the [Buildkite Nightly Job](https://buildkite.com/materialize/nightly), click the down arrow button
 at the top right and select `New Build`. Put the **full SHA** of your commit in `Commit` and the name
 of your branch in `Branch` including the Github username you forked with, e.g. `username:branch`.
 Click `Create Build` and wait for the build start, at which point you will

misc/python/materialize/buildkite_insights/annotation_search/README.md

@@ -15,31 +15,32 @@ usage: buildkite-annotation-search [-h]
                                    [--only-failed-builds]
                                    [--only-failed-build-step-key ONLY_FAILED_BUILD_STEP_KEY]
                                    [--use-regex]
-                                   {cleanup,coverage,deploy,deploy-lsp,deploy-mz,deploy-website,license,nightlies,release-qualification,security,sql-logic-tests,tests,www} pattern
+                                   {cleanup,coverage,deploy,deploy-mz-lsp-server,deploy-mz,deploy-website,license,nightly,release-qualification,security,slt,test,www}
+                                   pattern
 ```
 
 ## Examples
 
 Builds that have an annotation containing `Error { kind: Db, cause: Some(DbError`
 
 ```
-bin/buildkite-annotation-search tests "Error { kind: Db, cause: Some(DbError"
+bin/buildkite-annotation-search test "Error { kind: Db, cause: Some(DbError"
 ```
 
 Builds that have an annotation containing `Error` and include a larger number of recent builds
 
 ```
-bin/buildkite-annotation-search tests --max-build-fetches 10 "Error"
+bin/buildkite-annotation-search test --max-build-fetches 10 "Error"
 ```
 
 Builds on branch `main` that have an annotation matching the regex pattern `cannot serve requested as_of AntiChain.*testdrive-materialized-1`
 
 ```
-bin/buildkite-annotation-search tests --branch main --use-regex "cannot serve requested as_of AntiChain.*testdrive-materialized-1"
+bin/buildkite-annotation-search test --branch main --use-regex "cannot serve requested as_of AntiChain.*testdrive-materialized-1"
 ```
 
 Nightly builds that failed and have an annotation containing `fivetran-destination action=describe`
 
 ```
-bin/buildkite-annotation-search nightlies --only-failed-builds "fivetran-destination action=describe"
+bin/buildkite-annotation-search nightly --only-failed-builds "fivetran-destination action=describe"
 ```

misc/python/materialize/buildkite_insights/buildkite_api/buildkite_config.py

@@ -14,14 +14,14 @@
     "cleanup",
     "coverage",
     "deploy",
-    "deploy-lsp",
+    "deploy-mz-lsp-server",
     "deploy-mz",
     "deploy-website",
     "license",
-    "nightlies",
+    "nightly",
     "release-qualification",
     "security",
-    "sql-logic-tests",
-    "tests",
+    "slt",
+    "test",
     "www",
 ]

misc/python/materialize/buildkite_insights/step_analysis/README.md

@@ -14,31 +14,31 @@ usage: buildkite-step-durations [-h]
                                 [--build-state {running,scheduled,passed,failing,failed,blocked,canceled,canceling,skipped,not_run,finished}]
                                 [--build-step-state {assigned,broken,canceled,failed,passed,running,scheduled,skipped,timed_out,unblocked,waiting,waiting_failed}]
                                 [--output-type {txt,txt-short,csv}]
-                                {cleanup,coverage,deploy,deploy-lsp,deploy-mz,deploy-website,license,nightlies,release-qualification,security,sql-logic-tests,tests,www}
+                                {cleanup,coverage,deploy,deploy-mz-lsp-server,deploy-mz,deploy-website,license,nightly,release-qualification,security,slt,test,www}
 ```
 
 ## Examples
 
 Recent executions of build step "AWS (Localstack)" in Nightly on all branches
 
 ```
-bin/buildkite-step-insights nightlies --build-step-key "aws-localstack" --branch "*"
+bin/buildkite-step-insights nightly --build-step-key "aws-localstack" --branch "*"
 ```
 
 Recent failures of build step "AWS (Localstack)" in Nightly on `main` branch
 
 ```
-bin/buildkite-step-insights nightlies --build-step-key "aws-localstack" --branch main --build-step-state "failed"
+bin/buildkite-step-insights nightly --build-step-key "aws-localstack" --branch main --build-step-state "failed"
 ```
 
 Many recent executions of build step "Cargo test" on `main` branch in builds that failed due to any step
 
 ```
-bin/buildkite-step-insights tests --build-step-key "cargo-test" --branch "main" --max-fetches 6 --build-state failed
+bin/buildkite-step-insights test --build-step-key "cargo-test" --branch "main" --max-fetches 6 --build-state failed
 ```
 
 Most recent executions of "Cargo test" on `main` branch
 
 ```
-bin/buildkite-step-insights tests --build-step-key "cargo-test" --branch "main" --fetch always
+bin/buildkite-step-insights test --build-step-key "cargo-test" --branch "main" --fetch always
 ```

src/transform/src/fusion/join.rs

@@ -63,7 +63,7 @@ impl crate::Transform for Join {
         //
         // TODO(#25918): This is a temporary solution which fixes the "Product
         // limits" issue observed in a failed Nightly run when the PR was first
-        // tested (https://buildkite.com/materialize/nightlies/builds/6670). We
+        // tested (https://buildkite.com/materialize/nightly/builds/6670). We
         // should re-evaluate if we need this ad-hoc re-normalization step when
         // LiteralLifting is removed in favor of EquivalencePropagation.
         if transformed {

test/mz-e2e/README.md

@@ -4,7 +4,7 @@ Mz test runs multiple commands to test the `mz` CLI.
 
 # Usage
 
-The mz-e2e is made to run alone and during nightlies.
+The mz-e2e is made to run alone and during nightly.
 
 # Running