You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit b60307e
Browse filesBrowse the repository at this point in the historyBrowse files
closes the window automatically once both are done.
35
+
36
+
# Publish the release
37
+
38
+
-[ ] On release day, squash-merge the approved preparation PR directly into `master` using admin
39
+
permissions (`Merge without waiting for requirements to be met (bypass rules)`). Do not use the merge queue.
40
+
41
+
The merge kicks off the [Tag approved release](https://github.com/vectordotdev/vector/actions/workflows/release_autotag.yml)
42
+
workflow, which creates the version tag and release branch at that exact commit.
43
+
The tag starts the release workflow; do not create the tag or release branch manually.
44
+
45
+
-[ ] Wait for [release workflow](https://github.com/vectordotdev/vector/actions/workflows/release.yml) to complete.
46
+
- If it fails, use **Re-run failed jobs** to continue the release.
47
+
-[ ] Confirm that the release changelog was published to https://vector.dev/releases/
48
+
- Refer to the internal releasing doc to monitor the deployment.
49
+
-[ ] Confirm that [Homebrew](https://github.com/vectordotdev/homebrew-brew) was released ([workflow](https://github.com/vectordotdev/homebrew-brew/actions/workflows/release.yml))
50
+
-[ ] Release Linux packages. Refer to the internal releasing doc.
- Pin VRL to latest released version rather than `main`
46
-
- 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
47
-
`distribution/docker/`. Update if so.
48
-
- Generate a new cue file for the release in `website/cue/reference/releases/`
49
-
- Copy VRL changelogs from the VRL version in the last Vector release as a new changelog entry
-[ ] Add description key to the generated cue file with a description of the release (see
63
-
previous releases for examples).
64
-
-[ ] Ensure any breaking changes are highlighted in the release upgrade guide.
65
-
-[ ] Ensure any deprecations are highlighted in the release upgrade guide.
66
-
-[ ] Review generated changelog entries to ensure they are understandable to end-users.
67
-
-[ ] Ensure the date matches the scheduled release date.
68
-
-[ ] Add a link to pending deprecation items from [DEPRECATIONS.md](https://github.com/vectordotdev/vector/blob/master/docs/DEPRECATIONS.md).
69
-
-[ ] PR review & approval.
70
-
71
-
# On the day of release
72
-
73
-
-[ ] 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.
-[ ] If there is a VRL version update, revert it and make it track the git `main` branch and then run `cargo update -p vrl`.
55
+
-[ ] Wait for the Helm chart release to push the Kubernetes manifests directly to `master` ([workflow](https://github.com/vectordotdev/vector/actions/workflows/release_manifests.yml)).
56
+
-[ ] Wait for the [Unfreeze master](https://github.com/vectordotdev/vector/actions/workflows/release_unfreeze.yml) workflow to finalize the release.
-[ ] Manually trigger the `trigger-package-release-pipeline-prod-stable` job.
58
58
-[ ] Push the release branch to update the remote (This should close the preparation branch PR).
59
59
-`git checkout "${RELEASE_BRANCH}" && git push`
60
-
-[ ] Release updated Helm chart. See [releasing Helm chart](https://github.com/vectordotdev/helm-charts#releasing).
61
-
-[ ] Once Helm chart is released, updated Vector manifests
62
-
- Run `cargo vdev build manifests` and open a PR with changes
63
-
-[ ] Add docker images to [https://github.com/DataDog/images](https://github.com/DataDog/images/tree/master/vector) to have them available internally.
64
-
- Follow the [instructions at the top of the mirror.yaml file](https://github.com/DataDog/images/blob/fbf12868e90d52e513ebca0389610dea8a3c7e1a/mirror.yaml#L33-L49).
60
+
-[ ] Review and squash-merge the Helm release PR, then wait for the chart release.
61
+
- The Vector release workflow starts [Helm release preparation](https://github.com/vectordotdev/helm-charts/actions/workflows/release-prepare.yml)
62
+
automatically for the latest stable Vector release.
63
+
- See [releasing Helm chart](https://github.com/vectordotdev/helm-charts/blob/develop/RELEASING.md) for the review steps.
64
+
-[ ] Once the Helm chart is released, wait for the Kubernetes manifests push to `master`.
65
+
- The chart release triggers [Refresh Kubernetes manifests](https://github.com/vectordotdev/vector/actions/workflows/release_manifests.yml),
66
+
which runs `cargo vdev build manifests` and, when the generated manifests differ,
67
+
commits and pushes them to `master` itself as the `vectordotdev-bot` — no PR, no review,
68
+
no merge queue. If the run reports no changes, the manifests already match the chart.
69
+
-[ ] Wait for the [Unfreeze master](https://github.com/vectordotdev/vector/actions/workflows/release_unfreeze.yml)
70
+
workflow to close the direct-push window after the manifests run succeeds.
71
+
- It removes the temporary `vectordotdev-bot`**Always** bypass from every ruleset in
72
+
`RELEASE_FREEZE_BOT_BYPASS`, then sets the `RELEASE_FREEZE_RULESET_ID` ruleset back to **Disabled**.
73
+
It waits for any pending release or manifests run and for open `vectordotdev-bot` PRs first,
74
+
and gives up after ten minutes, leaving the freeze active.
75
+
- Run it manually with `workflow_dispatch` if the release never starts the manifests workflow, if that
76
+
run fails, or to retry a failed closeout.
77
+
A manual run makes the same checks unless you set `force`, which closes the window anyway.
78
+
65
79
-[ ] Cherry-pick any release commits from the release branch that are not on `master`, to `master`
66
-
-[ ] Reset the `website` branch to the `HEAD` of the release branch to update https://vector.dev
Copy file name to clipboardExpand all lines: .github/PULL_REQUEST_TEMPLATE.md
+6-51Lines changed: 6 additions & 51 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,73 +2,28 @@
2
2
<!-- Please provide a brief summary about what this PR does.
3
3
This should help the reviewers give feedback faster and with higher quality. -->
4
4
5
+
### References
6
+
<!-- Closes: <#issue/#PR or full link> -->
7
+
<!-- Related: <#issue/#PR or full link> -->
8
+
5
9
## Vector configuration
6
10
<!-- Include Vector configuration(s) you used to test and debug your changes. -->
7
11
8
12
## How did you test this PR?
9
13
<!-- Please describe how you tested your changes. Also include any information about your setup. -->
10
14
11
-
## Change Type
12
-
13
-
-[ ] Bug fix
14
-
-[ ] New feature
15
-
-[ ] Dependencies
16
-
-[ ] Non-functional (chore, refactoring, docs)
17
-
-[ ] Performance
18
-
19
-
## Is this a breaking change?
20
-
21
-
-[ ] Yes
22
-
-[ ] No
23
-
24
15
## Does this PR include user facing changes?
25
16
<!-- If this PR alters Vector behavior in any way, for example, it adds a new config field or changes internal metrics it is considered a user facing change.
26
17
Changes to CI, website, playground and similar are generally not considered user facing -->
27
18
28
19
-[ ] Yes. Please add a changelog fragment based on our [guidelines](https://github.com/vectordotdev/vector/blob/master/changelog.d/README.md).
29
20
-[ ] No. A maintainer will apply the `no-changelog` label to this PR.
- Do not hesitate to use `@vectordotdev/vector` to reach out to us regarding this PR.
44
-
- Some CI checks run only after we manually approve them.
45
-
- We recommend adding a `pre-push` hook, please see [this template](https://github.com/vectordotdev/vector/blob/master/CONTRIBUTING.md#Pre-push).
46
-
- Alternatively, we recommend running the following locally before pushing to the remote branch:
47
-
-`make fmt`
48
-
-`make check-clippy` (if there are failures it's possible some of them can be fixed with `make clippy-fix`)
49
-
-`make test`
26
+
- Before pushing, follow our [pre-push guidance](https://github.com/vectordotdev/vector/blob/master/CONTRIBUTING.md#pre-push).
50
27
- After a review is requested, please avoid force pushes to help us review incrementally.
51
28
- Feel free to push as many commits as you want. They will be squashed into one before merging.
52
29
- For example, you can run `git merge origin master` and `git push`.
53
-
- If this PR introduces changes Vector dependencies (modifies `Cargo.lock`), please
54
-
run `make 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 on the [dd-rust-license-tool](https://crates.io/crates/dd-rust-license-tool).
55
-
56
-
57
-
<!--
58
-
Your PR title must conform to the conventional commit spec:
* `scope` = Optional when `type` is "chore" or "docs", available scopes https://github.com/vectordotdev/vector/blob/master/.github/workflows/semantic.yml#L31
66
-
* `description` = short description of the change
67
-
68
-
Examples:
69
-
70
-
* enhancement(file source): Add `sort` option to sort discovered files
71
-
* feat(new source): Initial `statsd` source
72
-
* fix(file source): Fix a bug discovering new files
0 commit comments