chore(deps): Bump hyper-openssl from 0.9.2 to 0.10.2

.github/CODEOWNERS

@@ -2,5 +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 @vectordotdev/documentation
+
+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/feature.yml

@@ -1,4 +1,5 @@
 name: Feature
+type: 'Feature'
 description: 🚀 Suggest a new feature.
 labels:
 - 'type: feature'

.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 (e.g.: 0.50.0)
+export NEW_VRL_VERSION=<new VRL version> # replace this with the actual new VRL version (e.g.: 0.30.0)
+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}"
+```
+
+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,55 @@ 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:
+- [ ] Make sure the release branch is in sync with origin/master and has only one squashed commit with all commits from the prepare branch. If you made a PR from the prepare branch into the release branch this should already be the case
+  - [ ] `git checkout "${RELEASE_BRANCH}"`
+  - [ ] `git show --stat HEAD` - This should show the squashed prepare commit
+  - [ ] `git diff HEAD~1 origin/master --quiet && echo "Same" || echo "Different"` - Should output `Same`
+  - Follow these steps if the release branch needs to be updated
+    - [ ] 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.
+      - [ ] Ensure release date in `website/cue/reference/releases/0.XX.Y.cue` matches current date.
+        - If this needs to be updated commit and squash it in the release branch
+    - [ ] Merge release preparation branch into the release branch
+        - `git switch "${RELEASE_BRANCH}" && git merge --ff-only "${PREP_BRANCH}"`
 
-- [ ] 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. 
-    - [ ] 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>`
 - [ ] 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 && git checkout v0.<current minor version> && git checkout -b website-prepare-v0.<new version number>`
+  - `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
@@ -17,38 +29,38 @@ Before the release:
         previous releases for examples).
 - [ ] 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/` and
-      updating version number
+- [ ] Create new release md file by copying an existing one in `./website/content/en/releases/`.
+  - 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.<new version number>`) 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 checkout prepare-v0.<new version number> && 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 co v0.<current minor version> && git merge --ff-only prepare-v0.<current minor version>.<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