[DO NOT LAND] Allow us to disable namespace listwatching

.github/CODEOWNERS

@@ -2,13 +2,14 @@
 
 .github/workflows/regression.yml @vectordotdev/vector @vectordotdev/single-machine-performance
 regression/config.yaml @vectordotdev/vector @vectordotdev/single-machine-performance
-docs/ @vectordotdev/ux-team @vectordotdev/documentation
-website/ @vectordotdev/ux-team
-website/content  @vectordotdev/documentation
-website/cue/reference @vectordotdev/documentation
 
-website/js @vectordotdev/vector-website
-website/layouts @vectordotdev/vector-website
-website/scripts @vectordotdev/vector-website
-website/data @vectordotdev/vector-website
-website/* @vectordotdev/vector-website
+docs/ @vectordotdev/vector @vectordotdev/ux-team @vectordotdev/documentation
+website/ @vectordotdev/vector @vectordotdev/ux-team
+website/content @vectordotdev/vector @vectordotdev/documentation
+website/cue/reference @vectordotdev/vector @vectordotdev/documentation
+
+website/js @vectordotdev/vector @vectordotdev/vector-website
+website/layouts @vectordotdev/vector @vectordotdev/vector-website
+website/scripts @vectordotdev/vector @vectordotdev/vector-website
+website/data @vectordotdev/vector @vectordotdev/vector-website
+website/* @vectordotdev/vector @vectordotdev/vector-website

.github/DISCUSSION_TEMPLATE/q-a.yml

@@ -0,0 +1,33 @@
+title: "Q&A"
+labels: [ q-a ]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Please fill out the following fields to help us assist you effectively.
+
+  - type: textarea
+    id: question
+    attributes:
+      label: Question
+      description: What are you trying to do? What issue are you encountering?
+
+  - type: textarea
+    id: config
+    attributes:
+      label: Vector Config
+      description: Your Vector configuration (please redact sensitive data)
+      placeholder: |
+        ```yaml
+        # your config
+        ```
+
+  - type: textarea
+    id: logs
+    attributes:
+      label: Vector Logs
+      description: Paste any relevant Vector logs or error messages.
+      placeholder: |
+        ```sh
+        Jul 10 14:32:02 vector[1234]: ERROR ...
+        ```

.github/ISSUE_TEMPLATE/minor-release.md

@@ -5,25 +5,46 @@ title: "Vector [version] release"
 labels: "domain: releasing"
 ---
 
-The week before the release:
+
+# Setup and Automation
+
+Note the preparation steps are now automated. First, alter/create release.env
+
+```shell
+export NEW_VECTOR_VERSION=<new Vector version> # replace this with the actual new version
+export MINOR_VERSION=$(echo "NEW_VECTOR_VERSION" | cut -d. -f2)
+export PREP_BRANCH=prepare-v-0-"${MINOR_VERSION}"-"${NEW_VECTOR_VERSION}"-website
+export RELEASE_BRANCH=v0."${MINOR_VERSION}"
+export NEW_VRL_VERSION=<new VRL version> # replace this with the actual new VRL version
+```
+
+and then source it by running `source ./release.env`
+
+# The week before the release
+
+## 1. Manual Steps
 
 - [ ] Cut a new release of [VRL](https://github.com/vectordotdev/vrl) if needed
-- [ ] Check for any outstanding deprecation actions in [DEPRECATIONS.md](https://github.com/vectordotdev/vector/blob/master/docs/DEPRECATIONS.md) and
-      take them (or have someone help you take them)
+  - VRL release steps: https://github.com/vectordotdev/vrl/blob/main/release/README.md
+
+## 2. Automated Steps
+
+Run the following:
+
+```shell
+cargo vdev release prepare --version "${NEW_VECTOR_VERSION}" --vrl-version "${NEW_VRL_VERSION}"
+```
+
+Automated steps include:
 - [ ] Create a new release branch from master to freeze commits
-  - `git fetch && git checkout origin/master && git checkout -b v0.<new version number> && git push -u`
+  - `git fetch && git checkout origin/master && git checkout -b "{RELEASE_BRANCH}" && git push -u`
 - [ ] Create a new release preparation branch from `master`
-  - `git checkout -b website-prepare-v0.<new version number> && git push -u`
+  - `git checkout -b "${PREP_BRANCH}" && git push -u`
 - [ ] Pin VRL to latest released version rather than `main`
 - [ ] Check if there is a newer version of [Alpine](https://alpinelinux.org/releases/) or
       [Debian](https://www.debian.org/releases/) available to update the release images in
       `distribution/docker/`. Update if so.
 - [ ] Run `cargo vdev build release-cue` to generate a new cue file for the release
-  - [ ] Add description key to the generated cue file with a description of the release (see
-        previous releases for examples).
-  - [ ] Ensure any breaking changes are highlighted in the release upgrade guide
-  - [ ] Ensure any deprecations are highlighted in the release upgrade guide
-  - [ ] Review generated changelog entries to ensure they are understandable to end-users
   - [ ] Copy VRL changelogs from the VRL version in the last Vector release as a new changelog entry
         ([example](https://github.com/vectordotdev/vector/blob/9c67bba358195f5018febca2f228dfcb2be794b5/website/cue/reference/releases/0.41.0.cue#L33-L64))
 - [ ] Update version number in `website/cue/reference/administration/interfaces/kubectl.cue`
@@ -32,35 +53,48 @@ The week before the release:
 - [ ] Create new release md file by copying an existing one in `./website/content/en/releases/` and
       updating version number
 - [ ] Commit these changes
-- [ ] Open PR against the release branch (`v0.<new version number>`) for review
-- [ ] PR approval
+- [ ] Open PR against the release branch (`"${RELEASE_BRANCH}"`) for review
+
+## 3. Manual Steps
+
+- [ ] Edit `website/cue/reference/releases/"${NEW_VECTOR_VERSION}".cue`
+  - [ ] Add description key to the generated cue file with a description of the release (see
+        previous releases for examples).
+  - [ ] Ensure any breaking changes are highlighted in the release upgrade guide
+  - [ ] Ensure any deprecations are highlighted in the release upgrade guide
+  - [ ] Review generated changelog entries to ensure they are understandable to end-users
+- [ ] Check for any outstanding deprecation actions in [DEPRECATIONS.md](https://github.com/vectordotdev/vector/blob/master/docs/DEPRECATIONS.md) and
+    take them (or have someone help you take them)
+- [ ] PR review & approval
 
-On the day of release:
+# On the day of release
 
 - [ ] Rebase the release preparation branch on the release branch
     - [ ] Squash the release preparation commits (but not the cherry-picked commits!) to a single
-        commit. This makes it easier to cherry-pick to master after the release. 
+        commit. This makes it easier to cherry-pick to master after the release.
     - [ ] Ensure release date in cue matches current date.
 - [ ] Merge release preparation branch into the release branch
-    - `git co v0.<new version number> && git merge --ff-only prepare-v0.<new version number>`
+    - `git switch "${RELEASE_BRANCH}" && git merge --ff-only "${PREP_BRANCH}"`
 - [ ] Tag new release
-  - [ ] `git tag v0.<minor>.0 -a -m v0.<minor>.0`
-  - [ ] `git push origin v0.<minor>.0`
+  - [ ] `git tag v"${NEW_VECTOR_VERSION}" -a -m v"${NEW_VECTOR_VERSION}"`
+  - [ ] `git push origin v"${NEW_VECTOR_VERSION}"`
 - [ ] Wait for release workflow to complete
-  - Discoverable via [https://github.com/timberio/vector/actions/workflows/release.yml](https://github.com/timberio/vector/actions/workflows/release.yml)
+  - Discoverable via [release.yml](https://github.com/vectordotdev/vector/actions/workflows/release.yml)
 - [ ] Reset the `website` branch to the `HEAD` of the release branch to update https://vector.dev
-  - [ ] `git checkout website && git reset --hard origin/v0.<new version number> && git push`
+  - [ ] `git switch website && git reset --hard origin/"${RELEASE_BRANCH}" && git push`
   - [ ] Confirm that the release changelog was published to https://vector.dev/releases/
     - The deployment is done by Amplify. You can see
       the [deployment logs here](https://dd-corpsite.datadoghq.com/logs?query=service%3Awebsites-vector%20branch%3Awebsite&agg_m=count&agg_m_source=base&agg_t=count&cols=host%2Cservice&fromUser=true&messageDisplay=inline&refresh_mode=sliding&storage=hot&stream_sort=time%2Casc&viz=stream).
 - [ ] Release Linux packages. See [`vector-release` usage](https://github.com/DataDog/vector-release#usage).
-  - Note: the pipeline inputs are the version number `v0.<new version number>` and a personal GitHub token.
+  - Note: the pipeline inputs are the version number `v"${NEW_VECTOR_VERSION}"` and a personal GitHub token.
   - [ ] Manually trigger the `trigger-package-release-pipeline-prod-stable` job.
 - [ ] Release updated Helm chart. See [releasing Helm chart](https://github.com/vectordotdev/helm-charts#releasing).
 - [ ] Once Helm chart is released, updated Vector manifests
     - Run `cargo vdev build manifests` and open a PR with changes
-- [ ] Add docker images to [https://github.com/DataDog/images](https://github.com/DataDog/images/tree/master/vector) to have them available internally.
-- [ ] Cherry-pick any release commits from the release branch that are not on `master`, to `master`
-- [ ] Bump the release number in the `Cargo.toml` on master to the next major release.
-  - Also, update `Cargo.lock` with: `cargo update -p vector`
+- [ ] Add docker images to [https://github.com/DataDog/images](https://github.com/DataDog/images/tree/master/vector) to have them available internally. ([Example PR](https://github.com/DataDog/images/pull/7104))
+- [ ] Create a new PR with title starting as `chore(releasing):`
+  - [ ] Cherry-pick any release commits from the release branch that are not on `master`, to `master`
+  - [ ] Bump the release number in the `Cargo.toml` on master to the next minor release.
+  - [ ] Also, update `Cargo.lock` with: `cargo update -p vector`
+  - [ ] If there is a VRL version update, revert it and make it track the git `main` branch and then run `cargo update -p vrl`.
 - [ ] Kick-off post-mortems for any regressions resolved by the release

.github/ISSUE_TEMPLATE/patch-release.md

@@ -5,10 +5,22 @@ title: "Vector [version] release"
 labels: "domain: releasing"
 ---
 
-Before the release:
+# Setup environment
+
+```shell
+export CURRENT_MINOR_VERSION = <current minor version> # e.g. 47
+export CURRENT_PATCH_VERSION = <current patch version> # e.g. 0
+export CURRENT_VERSION="${RELEASE_BRANCH}"."${CURRENT_PATCH_VERSION}"
+export NEW_PATCH_VERSION = <new patch version> # e.g. 1
+export NEW_VERSION="${RELEASE_BRANCH}"."${NEW_PATCH_VERSION}"
+export RELEASE_BRANCH=v0."${CURRENT_MINOR_VERSION}"
+export PREP_BRANCH=prepare-v-0-"${CURRENT_MINOR_VERSION}"-"${NEW_PATCH_VERSION}"-website
+```
+
+# Before the release
 
 - [ ] Create a new release preparation branch from the current release branch
-  - `git fetch --all && git checkout v0.<current minor version> && git checkout -b website-prepare-v0-<current minor version>-<new patch>
+  - `git fetch --all && git checkout "${RELEASE_BRANCH}" && git checkout -b "${PREP_BRANCH}""`
 - [ ] Cherry-pick in all commits to be released from the associated release milestone
   - If any merge conflicts occur, attempt to solve them and if needed enlist the aid of those familiar with the conflicting commits.
 - [ ] Bump the release number in the `Cargo.toml` to the current version number
@@ -18,37 +30,37 @@ Before the release:
 - [ ] Update version number in `distribution/install.sh`
 - [ ] Add new version to `website/cue/reference/versions.cue`
 - [ ] Create new release md file by copying an existing one in `./website/content/en/releases/`.
-  - Update the version number to `v0.<current minor version>.<patch>` and increase the `weight` by 1.
+  - Update the version number to `"${NEW_VERSION}"` and increase the `weight` by 1.
 - [ ] Run `cargo check` to regenerate `Cargo.lock` file
 - [ ] Commit these changes
-- [ ] Open PR against the release branch (`v0.<current minor version>`) for review
+- [ ] Open PR against the release branch (`"${RELEASE_BRANCH}"`) for review
 - [ ] PR approval
 
-On the day of release:
+# On the day of release
 
 - [ ] Ensure release date in cue matches current date.
 - [ ] Rebase the release preparation branch on the release branch
   - Squash the release preparation commits (but not the cherry-picked commits!) to a single
     commit. This makes it easier to cherry-pick to master after the release.
-  - `git fetch --all && git checkout website-prepare-v0-<current minor version>-<new patch> && git rebase -i v0.<current minor version>`
+  - `git fetch --all && git checkout website-prepare-v0-"${CURRENT_MINOR_VERSION}"-"${NEW_PATCH_VERSION}" && git rebase -i "${RELEASE_BRANCH}"`
 - [ ] Merge release preparation branch into the release branch
-  - `git checkout v0.<current minor version> && git merge --ff-only website-prepare-v0-<current minor version>-<new patch>`
+  - `git checkout "${RELEASE_BRANCH}" && git merge --ff-only website-prepare-v0-"${CURRENT_MINOR_VERSION}"-"${NEW_PATCH_VERSION}"`
 - [ ] Tag new release
-  - [ ] `git tag v0.<minor>.<patch> -a -m v0.<minor>.<patch>`
-  - [ ] `git push origin v0.<minor>.<patch>`
+  - [ ] `git tag "${NEW_VERSION}" -a -m "${NEW_VERSION}"`
+  - [ ] `git push origin "${NEW_VERSION}"`
 - [ ] Wait for release workflow to complete
   - Discoverable via [https://github.com/timberio/vector/actions/workflows/release.yml](https://github.com/timberio/vector/actions/workflows/release.yml)
 - [ ] Release Linux packages. See [`vector-release` usage](https://github.com/DataDog/vector-release#usage).
-  - Note: the pipeline inputs are the version number `v0.<new version number>` and a personal GitHub token.
+  - Note: the pipeline inputs are the version number `"${CURRENT_VERSION}"` and a personal GitHub token.
   - [ ] Manually trigger the `trigger-package-release-pipeline-prod-stable` job.
 - [ ] Push the release branch to update the remote (This should close the preparation branch PR).
-  - `git checkout v0.<current minor version> && git push`
+  - `git checkout "${RELEASE_BRANCH}" && git push`
 - [ ] Release updated Helm chart. See [releasing Helm chart](https://github.com/vectordotdev/helm-charts#releasing).
 - [ ] Once Helm chart is released, updated Vector manifests
   - Run `cargo vdev build manifests` and open a PR with changes
 - [ ] Add docker images to [https://github.com/DataDog/images](https://github.com/DataDog/images/tree/master/vector) to have them available internally.
   - Follow the [instructions at the top of the mirror.yaml file](https://github.com/DataDog/images/blob/fbf12868e90d52e513ebca0389610dea8a3c7e1a/mirror.yaml#L33-L49).
 - [ ] Cherry-pick any release commits from the release branch that are not on `master`, to `master`
 - [ ] Reset the `website` branch to the `HEAD` of the release branch to update https://vector.dev
-  - [ ] `git checkout website && git reset --hard origin/v0.<current minor version>.<patch> && git push`
+  - [ ] `git checkout website && git reset --hard origin/"${RELEASE_BRANCH}" && git push`
 - [ ] Kick-off post-mortems for any regressions resolved by the release

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,26 +1,13 @@
-<!--
-  Your PR title must conform to the conventional commit spec:
-  https://www.conventionalcommits.org/en/v1.0.0/
-
-  <type>(<scope>)!: <description>
-
-  * `type` = chore, enhancement, feat, fix, docs, revert
-  * `!` = OPTIONAL: signals a breaking change
-  * `scope` = Optional when `type` is "chore" or "docs", available scopes https://github.com/vectordotdev/vector/blob/master/.github/workflows/semantic.yml#L31
-  * `description` = short description of the change
-
-Examples:
-
-  * enhancement(file source): Add `sort` option to sort discovered files
-  * feat(new source): Initial `statsd` source
-  * fix(file source): Fix a bug discovering new files
-  * chore(external docs): Clarify `batch_size` option
--->
-
 ## Summary
 <!-- Please provide a brief summary about what this PR does.
 This should help the reviewers give feedback faster and with higher quality. -->
 
+## Vector configuration
+<!-- Include Vector configuration(s) you used to test and debug your changes. -->
+
+## How did you test this PR?
+<!-- Please describe how you tested your changes. Also include any information about your setup. -->
+
 ## Change Type
 - [ ] Bug fix
 - [ ] New feature
@@ -31,38 +18,50 @@ This should help the reviewers give feedback faster and with higher quality. -->
 - [ ] Yes
 - [ ] No
 
-## How did you test this PR?
-<!-- Please describe your testing plan here.
-Sharing information about your setup and the Vector configuration(s) you used (when applicable) is highly recommended.
-Providing this information upfront will facilitate a smoother review process. -->
-
 ## Does this PR include user facing changes?
 
 - [ ] Yes. Please add a changelog fragment based on our [guidelines](https://github.com/vectordotdev/vector/blob/master/changelog.d/README.md).
-- [ ] No. A maintainer will apply the "no-changelog" label to this PR.
+- [ ] No. A maintainer will apply the `no-changelog` label to this PR.
+
+## References
+
+<!--
+- Closes: #<issue number>
+- Related: #<issue number>
+- Related: #<PR number>
+-->
 
 ## Notes
 - Please read our [Vector contributor resources](https://github.com/vectordotdev/vector/tree/master/docs#getting-started).
 - Do not hesitate to use `@vectordotdev/vector` to reach out to us regarding this PR.
-- The CI checks run only after we manually approve them.
+- Some CI checks run only after we manually approve them.
   - We recommend adding a `pre-push` hook, please see [this template](https://github.com/vectordotdev/vector/blob/master/CONTRIBUTING.md#Pre-push).
   - Alternatively, we recommend running the following locally before pushing to the remote branch:
     - `cargo fmt --all`
     - `cargo clippy --workspace --all-targets -- -D warnings`
     - `cargo nextest run --workspace` (alternatively, you can run `cargo test --all`)
-    - `./scripts/check_changelog_fragments.sh`
 - After a review is requested, please avoid force pushes to help us review incrementally.
   - Feel free to push as many commits as you want. They will be squashed into one before merging.
   - For example, you can run `git merge origin master` and `git push`.
 - If this PR introduces changes Vector dependencies (modifies `Cargo.lock`), please
   run `cargo vdev build licenses` to regenerate the [license inventory](https://github.com/vectordotdev/vrl/blob/main/LICENSE-3rdparty.csv) and commit the changes (if any). More details [here](https://crates.io/crates/dd-rust-license-tool).
 
-## References
-
-<!-- Please list any issues closed by this PR. -->
 
 <!--
-- Closes: <issue link>
--->
+  Your PR title must conform to the conventional commit spec:
+  https://www.conventionalcommits.org/en/v1.0.0/
+
+  <type>(<scope>)!: <description>
 
-<!-- Any other issues or PRs relevant to this PR? Feel free to list them here. -->
+  * `type` = chore, enhancement, feat, fix, docs, revert
+  * `!` = OPTIONAL: signals a breaking change
+  * `scope` = Optional when `type` is "chore" or "docs", available scopes https://github.com/vectordotdev/vector/blob/master/.github/workflows/semantic.yml#L31
+  * `description` = short description of the change
+
+Examples:
+
+  * enhancement(file source): Add `sort` option to sort discovered files
+  * feat(new source): Initial `statsd` source
+  * fix(file source): Fix a bug discovering new files
+  * chore(external docs): Clarify `batch_size` option
+-->