From 069c114484f7541321002cc4a2a5619cbd340434 Mon Sep 17 00:00:00 2001
From: Julia <611228+hithwen@users.noreply.github.com>
Date: Mon, 30 May 2022 12:35:39 +0200
Subject: [PATCH] =?UTF-8?q?Remove=20information=20about=20agent=20and=20co?=
=?UTF-8?q?re=20integrations=20releases=20as=20it=20h=E2=80=A6=20(#12089)?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* Remove information about agent and core integrations releases as it has been moved internally
---
docs/developer/ddev/configuration.md | 19 --
.../process/agent-release/post-release.md | 68 -----
.../process/agent-release/pre-release.md | 164 -----------
docs/developer/process/integration-release.md | 264 +-----------------
mkdocs.yml | 3 -
5 files changed, 2 insertions(+), 516 deletions(-)
delete mode 100644 docs/developer/process/agent-release/post-release.md
delete mode 100644 docs/developer/process/agent-release/pre-release.md
diff --git a/docs/developer/ddev/configuration.md b/docs/developer/ddev/configuration.md
index bf4909f1d17ba..f6a514a0a3206 100644
--- a/docs/developer/ddev/configuration.md
+++ b/docs/developer/ddev/configuration.md
@@ -86,22 +86,3 @@ If not:
1. Create a [personal access token][github-personal-access-token] with `public_repo` and `read:org` permissions
1. Run `ddev config set github.token` then paste the token
1. [Enable single sign-on][github-saml-single-sign-on] for the token
-
-## Trello
-
-To participate as an [Agent release manager](../process/agent-release/pre-release.md), you need to set `trello.key`/`trello.token` in your config file.
-
-Run `ddev config show` to see if your Trello key and token is set.
-
-If not:
-
-1. Go to `https://trello.com/app-key` and copy your API key
-1. Run `ddev config set trello.key` then paste your API key
-1. Go to `https://trello.com/1/authorize?key=<KEY>&name=<NAME>&scope=read,write&expiration=never&response_type=token`,
- where `<KEY>` is your API key and `<NAME>` is the name to give your token, e.g. `ReleaseTestingYourName`.
- Authorize access and copy your token.
-1. Run `ddev config set trello.token` and paste your token
-
-### Card Assignment
-
-When automatically assigning [QA cards](../process/agent-release/pre-release.md#create-items), the Trello users which are members of the `Agent Release Sprint` Trello board will be fetched and cards will be assigned at random to them. Make sure people in your team are all members of the `Agent Release Sprint` board.
diff --git a/docs/developer/process/agent-release/post-release.md b/docs/developer/process/agent-release/post-release.md
deleted file mode 100644
index 3a3d3831eddd2..0000000000000
--- a/docs/developer/process/agent-release/post-release.md
+++ /dev/null
@@ -1,68 +0,0 @@
-# Post release
-
------
-
-## Finalize
-
-On the day of the final stable release, [tag](pre-release.md#tag) the [branch](pre-release.md#branch) with `<MAJOR>.<MINOR>.0`.
-
-After the main Agent release manager confirms successful deployment to a few targets, create a branch based on `master` and run:
-
-```
-ddev agent changelog
-ddev agent integrations
-```
-
-See more options for [`ddev agent changelog`](../../ddev/cli.md#ddev-agent-changelog) and
-[`ddev agent integrations`](../../ddev/cli.md#ddev-agent-integrations).
-
-Run the following commands to update the contents:
-
-1. `ddev agent changelog -w -f` to update the existing [`AGENT_CHANGELOG`][agent-changelog] file
-2. `ddev agent integrations -w -f` to update the existing [`AGENT_INTEGRATIONS`][agent-integrations] file.
-3. `ddev agent integrations-changelog -w` to add Agent version to existing `CHANGELOG.md` releases of integrations.
-
-Create a pull request and wait for approval before merging.
-
-## Patches
-
-!!! important
- Only critical fixes are included in patches. See definition for
- [critical fixes](https://github.com/DataDog/datadog-floss-guidance/blob/master/docs/severity.md#critical).
-
-Releases after the final Agent release should be reserved for critical issues only. Cherry-picking commits and releases for
- the patch release is mostly similar to the process for [preparing release candidates](pre-release.md#release-candidates).
-
-However, it's possible that from the time [code freeze ended](pre-release.md#release-week) and a bugfix is needed,
-the integration has other non-critical commits or was released.
-
-Given the effort of QA-ing the Agent release, any new changes should be _carefully_ selected and included for the patch.
-
-The next section will describe the process for preparing the patch release candidates.
-
-### Multiple check releases between bugfix release
-
-There are two main cases where the release manager will have to release integrations off of the release branch: the freeze has lifted and changes to an integration have been merged after freeze and before a bugfix for an RC, or a [patch release](#patches) is required. To release an integration off of the release branch, perform the following steps:
-
-1. Cherry-pick the bugfix commit to the [release branch](pre-release.md#branch).
-
-2. Prepare the release of the integration.
- - Create a branch based off of the release branch.
- - Run the [integration release](../integration-release.md#new-integrations) command on that branch.
- - Make a pull request with that branch, then merge it to the release branch.
- - Note: if there are multiple integrations to release, do not use `ddev release make all --exclude <INTGS>`. Once `master` is unfrozen, releasing `all` may result in unwanted and unshipped changes to the release branch if new changes are introduced. Use `ddev release make check1 check2` instead if releasing `check1` and `check2`.
-
-3. Releases from the `master` branch automatically trigger the release pipeline when the PRs are merged in. If you're releasing from a release branch however, you have to manually trigger the release pipeline by [tagging the release](../../ddev/cli.md#ddev-release-tag):
-
- `ddev release tag <INTEGRATION>`
-
-4. Pull the latest release branch so your branch has the bugfix commit and release commit.
-
-5. [Tag](pre-release.md#tag) the branch with the new bumped version `<MAJOR>.<MINOR>.<PATCH>-rc.1`.
-
-6. After the release has been made, make a PR to `master` with the updates to `CHANGELOG.md`, [agent release requirements](https://github.com/DataDog/integrations-core/blob/master/requirements-agent-release.txt), and `__about__.py` of the integrations that were released on the release branch. Do not include the change to the in-toto file. If the current version of `__about__.py` is higher on `master` than in the release branch, **only update** the `CHANGELOG.md` in this PR.
-
- !!! important
- Do not merge this PR unless the release tag from the previous PR has been pushed or the release pipeline will incorrectly attempt to release from `master`.
-
-7. Finally, if a patch release was performed, follow the same steps to [finalize the release](#finalize).
diff --git a/docs/developer/process/agent-release/pre-release.md b/docs/developer/process/agent-release/pre-release.md
deleted file mode 100644
index 5d421e5fcb50e..0000000000000
--- a/docs/developer/process/agent-release/pre-release.md
+++ /dev/null
@@ -1,164 +0,0 @@
-# Pre release
-
------
-
-<div align="center">
- <video preload="auto" autoplay loop muted>
- <source src="https://media.giphy.com/media/12FdFGei62ZKKI/giphy.mp4" type="video/mp4"></source>
- </video>
-</div>
-
-A new minor version of the Agent is released every 6 weeks (approximately). Each release
-ships a snapshot of [integrations-core][].
-
-## Setup
-
-Ensure that you have configured the following:
-
-- [GitHub](../../ddev/configuration.md#github) credentials
-- [Trello](../../ddev/configuration.md#trello) credentials
-
-## Before Freeze
-
-1. _One week before freeze_: Make dependency update PRs:
- * Create a new branch
- * Run `ddev dep updates --sync --batch-size 10`
- * Create a PR with the updated dependencies
- * If the CI is failing and there are compatibility reasons, investigate the errors. You may have to add the dependency that is causing the error to the set of [IGNORED_DEPS](https://github.com/DataDog/integrations-core/blob/master/datadog_checks_dev/datadog_checks/dev/tooling/commands/dep.py) and revert that particular dependency bump.
-
- If the first PR process does not take long, try another batch of updates and repeat the above process. Overall, this step is not mandatory but it is important to keep our dependencies up to date.
-
-2. _The week of freeze_: Update [style dependencies](https://github.com/DataDog/integrations-core/blob/master/datadog_checks_dev/datadog_checks/dev/plugin/tox.py) to the latest versions (except if comments say otherwise) with a PR. Example: `ISORT_DEP`, `BLACK_DEP`, etc.
-3. _The day before freeze_: Communicate to teams that contribute to `integrations-core` that freeze is happening on Friday.
-4. _The day of freeze_: Manually run and fix the [base package dependency check build](https://dev.azure.com/datadoghq/integrations-core/_build?definitionId=52) as needed.
-5. _The day of freeze_: Check if the [master](https://dev.azure.com/datadoghq/integrations-core/_build?definitionId=29), [py2](https://dev.azure.com/datadoghq/integrations-core/_build?definitionId=38), and [base_check](https://dev.azure.com/datadoghq/integrations-core/_build?definitionId=52) builds are green. It is important to make sure CI is in a stable state before freeze.
-
-
-## Freeze
-
-At midnight (EDT/EST) on the Friday before QA week we freeze, at which point the release manager will release
-all integrations with pending changes then branch off. If no new PRs are active at the end of business hours (EDT/EST), try to make the initial [release](#release) then, so that the QA process can start on the next Monday morning.
-
-The release manager will initiate code freeze of the `integrations-core` repo using the [mergefreeze](https://datadoghq.atlassian.net/wiki/spaces/agent/pages/2255421890/mergefreeze) Github App by clicking the `Freeze now` button. The mergefreeze app will add a failing `mergefreeze` CI check on all PRs targeting the protected branch, preventing them from being merged by non-admin users.
-
-### Release
-
-1. Make a pull request to release [any new integrations](../integration-release.md#new-integrations), then merge it and pull `master`
-1. Make a pull request to release [all changed integrations](../integration-release.md#bulk-releases), then merge it and pull `master`
- * Get 2+ thorough reviews on the changelogs. Entries should have appropriate SemVer levels (e.g. `Changed` entries must refer to breaking changes only). See also [PR guidelines](../../guidelines/pr.md).
- * Consider x-posting the PR to Agent teams that have integrations in `integrations-core`, so they can check relevant changelogs too.
-
-!!! important
- [Update PyPI](../integration-release.md#pypi) if you released `datadog_checks_base` or `datadog_checks_dev`.
-
-
-### Branch
-
-We create a release branch on `integrations-core` at the beginning of the freeze. The purpose of this branch is to track all of the integrations that are shipped with the Agent for each release. The Agent RCs are built with the source code of integrations on the release branch.
-
-1. Create a branch based on `master` named after the highest version of the Agent being released in the form `<MAJOR>.<MINOR>.x`
-1. Push the branch to GitHub
-
-### Tag
-
-Run:
-
-```
-git tag <MAJOR>.<MINOR>.0-rc.1 -m <MAJOR>.<MINOR>.0-rc.1
-git push origin <MAJOR>.<MINOR>.0-rc.1
-```
-
-We should create a tag for each new RC, regardless of whether there are new changes from `integrations-core` in the RC.
-
-## QA week
-
-We test all changes to integrations that were introduced since the last release.
-
-### Create items
-
-Create an item for every change in [our board](https://trello.com/b/ICjijxr4/agent-release-sprint) using
-the Trello subcommand called [testable](../../ddev/cli.md#ddev-release-trello-testable).
-
-For example:
-
-```
-ddev release trello testable 7.17.1 7.18.0-rc.1
-```
-or if the tag is not ready yet:
-```
-ddev release trello testable 7.17.1 origin/master
-```
-
-would select all commits that were merged between the Git references.
-
-The command will display each change and prompt you to assign a team or skip. Purely documentation changes are automatically skipped.
-
-Cards are automatically assigned to members of [the team](../../ddev/configuration.md#card-assignment).
-
-### Release candidates
-
-The main Agent release manager will increment and build a new `rc` every day a bug fix needs to be tested until all QA is complete.
-
-Before each build is triggered:
-
-1. Ensure all PRs have a `category/X` label.
-2. Merge any fixes that have been approved and pull `master`.
-3. Release [all changed integrations](../integration-release.md#bulk-releases) except for `datadog_checks_dev`.
-
-For each fix merged, you must cherry-pick to the [branch](#branch):
-
-1. The commit to `master` itself
-1. The release commit, so the shipped versions match the individually released integrations
-
-After all fixes have been cherry-picked:
-
-1. Push the changes to GitHub
-1. [Tag](#tag) with the appropriate `rc` number even if there were no changes
-
-After the RC build is done:
-
-1. Manually run an [Agent Azure Pipeline](https://dev.azure.com/datadoghq/integrations-core/_build?definitionId=60) using the [release branch](#branch), and the latest RC built. Select the options to run both Python 2 and Python 3 tests. This will run all the e2e tests against the current agent docker RCs.
-
- !!! note
- Image for Windows-Python 2 might not be built automatically for each RC. In order to build it, trigger the [dev_branch-a6-windows](https://github.com/DataDog/datadog-agent/blob/1b99fefa1d31eef8631e6343bdd2a4cf2b11f82d/.gitlab/image_deploy/docker_windows.yml#L43-L61) job in the datadog-agent Gitlab pipeline building the RC (link shared by the release coordinator). Once the job has finished running, change the `Windows Agent Docker Image for Python 2` parameter to the name of the newly built image, which is in the format: `datadog/agent-dev:<MAJOR>-<MINOR>-0-rc-<RC>-py2-win-servercore`. For example:
- ```
- datadog/agent-dev:7-33-0-rc-9-py2-win-servercore
- ```
-
- !!! note
- In some cases, the CI may be broken on both the release branch and `master` during release week due to testing limits or development dependency changes and **not** code changes. Fixes for these issues will be merged to the `master` branch, and if they aren't include on the release branch the Azure pipelines will fail. If these changes are only test related (no code change), the CI fixes can be cherry-picked to the release branch and don't need a release. This will ensure that the Azure pipelines only fail on code-related errors.
-
-2. Create and assign new [QA cards](#create-items) for the newly built RC based off of the newest tag, for example, if the new RC is 7.8.0-rc.8, you will run:
-```
-ddev release trello testable 7.8.0-rc.7 7.8.0-rc.8
-```
-
-
-### Communication
-
-The Agent Release Manager will post a [daily status](../../ddev/cli.md#ddev-release-trello-status) for the entire release cycle.
-Reply in the thread with any pending PRs meant for the next RC and update the spreadsheet `PRs included in Agent RCs`.
-
-Since it can be hard to predict when and if a new RC will be built, it is better to cherry-pick, release, and tag new integrations for RCs proactively so the creation of RCs is not held back. If new fixes for integrations are discovered after you have already tagged the branch, then you can always delete the tag from Github and locally, release the new changes, and re-tag.
-
-### Logs
-
-Each release candidate is deployed in a staging environment. We observe the `WARN` or `ERROR` level logs filtered with the facets
- `Service:datadog-agent` and `index:main` and `LogMessage` to see if any unexpected or frequent errors start occurring that was not caught
- during QA.
-
-
-## Post Freeze
-
-After QA week ends, the code freeze is lifted when all original QA cards are tested. Bugfixes will be introduced and need to be tested, but that does not block lifting the freeze. The release manager will continue
-the same process outlined above, but with more complexities due to the freeze being lifted.
-
-Notify the Agent Release Manager when code freeze ends.
-
-### Releasing integrations off of the release branch post-freeze
-
-If the freeze has lifted and changes to an integration have been merged after freeze and before a bugfix for an RC, you will need to release an integration off the release branch. See this [section](post-release.md#multiple-check-releases-between-bugfix-release) for more details. After releasing, continue following the same steps for creating [release candidates](#release-candidates)
-
-
-!!! note
- Sometimes, an RC will need to be made with an integration that can be released off of the release branch, and an integration that can be released off of `master`. In this case, you can make two release PRs, one for the release branch, and one for `master`. The order of creation for these does not matter.
diff --git a/docs/developer/process/integration-release.md b/docs/developer/process/integration-release.md
index c60a66e13c2c9..89e6e9af13869 100644
--- a/docs/developer/process/integration-release.md
+++ b/docs/developer/process/integration-release.md
@@ -1,7 +1,5 @@
# Integration release
------
-
Each Agent integration has its own release cycle. Many integrations are actively developed and released often while
some are rarely touched (usually indicating feature-completeness).
@@ -50,26 +48,7 @@ To see all checks that need to be released, run `ddev release show ready`.
It is critical the branch name is not in the form `<USERNAME>/<INTEGRATION_NAME>-<NEW_VERSION>` because one of
our Gitlab jobs is triggered whenever a Git reference matches that pattern, see !3843 & !3980.
-2. Make the release.
-
- ### Core
-
- ```
- ddev release make <INTEGRATION>
- ```
-
- You may need to touch your Yubikey multiple times.
-
- This will automatically:
-
- * update the version in `<INTEGRATION>/datadog_checks/<INTEGRATION>/__about__.py`
- * update the changelog
- * update the `requirements-agent-release.txt` file
- * update [in-toto metadata](../meta/cd.md)
- * commit the above changes
-
- ### Third party
-
+2. Make the release (Third party integrations).
* Update the version on `datadog_checks/<INTEGRATION>/__about__.py`.
* Update the CHANGELOG.md file This file can be automatically updated by `ddev` using the following command:
@@ -95,246 +74,7 @@ To see all checks that need to be released, run `ddev release show ready`.
You need to run certain backend jobs if any changes modified integration metadata or assets such as dashboards.
If you are a contributor a datadog employee will handle this.
-## Bulk releases (core integrations only)
-
-To create a release for every integration that has changed, use `all` as the integration name in the `ddev release make`
-step above.
-
-```
-ddev release make all
-```
-
-You may also pass a comma-separated list of checks to skip using the `--exclude` option, e.g.:
-
-```
-ddev release make all --exclude datadog_checks_dev
-```
-
-Note: releasing `all` will update the `.in-toto` file to include every integration, not just the changed integrations. This may result in an unnecessarily large `.in-toto` file if only releasing a few integrations.
-
-!!! warning
- There is a known GitHub limitation where if an issue has too many labels (100), its state cannot be modified.
- If you cannot merge the pull request:
-
- 1. Run the [remove-labels](../ddev/cli.md#ddev-meta-scripts-remove-labels) command
- 1. After merging, manually add back the `changelog/no-changelog` label
-
-Another option for bulk releases is selectively choosing the integrations to release. For example, if you are just releasing `check1` and `check2`:
-
-```
-ddev release make check1 check2
-```
-
-## Betas (core integrations only)
-
-Creating pre-releases follows the same workflow except you do not open a pull request but rather release directly from a branch.
-
-In the `ddev release make` step set `--version` to `[major|minor|patch],[rc|alpha|beta]`.
-
-For example, if the current version of an integration is `1.1.3`, the following command will bump it to `1.2.0-rc.1`:
-
-```
-ddev release make <INTEGRATION> --version minor,rc
-```
-
-After pushing the release commits to GitHub, run:
-
-```
-ddev release tag <INTEGRATION>
-```
-
-This manually triggers the [build pipeline](../meta/cd.md).
-
-To increment the version, omit the first part, e.g.:
-
-```
-ddev release make <INTEGRATION> --version rc
-```
-
-## New integrations
-
-### Core integrations
-
-To bump a new core integration to `1.0.0` if it is not already there, run:
-
-```
-ddev release make <INTEGRATION> --new
-```
-
-To ensure this for all integrations, run:
-
-```
-ddev release make all --new
-```
-
-If a release was created, run:
-
-```
-ddev agent requirements
-```
-
-### Third party integrations
+## New integrations (third party integrations)
For first time releases of third party integrations, simply merge the integration to master and a release will be
triggered with the specified version number in the about file.
-
-
-## Base package releases
-
-If you released `datadog_checks_base` or `datadog_checks_dev` then these must be uploaded to [PyPI][]
-for use by [integrations-extras][].
-
-This is automatically handled by two GitHub Action jobs: [release-base.yml][] and [release-dev.yml][].
-
-In case you need to do it manually:
-
-```
-ddev release upload datadog_checks_[base|dev]
-```
-
-## Troubleshooting
-
-#### Error signing with Yubikey
-- If you encounter errors when signing with your Yubikey, ensure you ran `gpg --import <YOUR_KEY_ID>.gpg.pub`.
-- If you receive this error when signing with your Yubikey, check if you have more than one Yubikey inserted in your computer. Try removing the Yubikey that's not used for signing and try signing again.
-
- ```
- File "/Users/<USER>/.pyenv/versions/3.9.4/lib/python3.9/site-packages/in_toto/runlib.py", line 529, in in_toto_run
- securesystemslib.formats.KEYID_SCHEMA.check_match(gpg_keyid)
- File "/Users/<USER>/.pyenv/versions/3.9.4/lib/python3.9/site-packages/securesystemslib/schema.py", line 1004, in check_match
- raise exceptions.FormatError(
- securesystemslib.exceptions.FormatError: '[none]' did not match 'pattern /[a-fA-F0-9]+$/'
- ```
-
-#### Build pipeline failed
-
-After merging the release PR, the [build pipeline](../meta/cd.md) can fail under a few cases. See below for steps on diagnosing the error and the corresponding fix.
-
-- A file in the pull request was modified without re-signing. View the `Files Changed` tab in the recently merged release PR and verify the `.in-toto/tag.<KEYID>.link` exists and the integration files were signed.
-
- To resolve this, you'll need to bootstrap metadata for every integration:
-
- 1. Checkout and pull the most recent version of the `master` branch.
-
- ```
- git checkout master
- git pull
- ```
-
- 1. Sign everything.
-
- ```
- ddev release make all --sign-only
- ```
-
- You may need to touch your Yubikey multiple times.
-
- 1. Push your branch to GitHub.
- 1. Manually trigger a build.
-
- ```
- git tag <USERNAME>bootstrap-1.0.0 -m <USERNAME>bootstrap-1.0.0
- ```
-
- The tag name is irrelevant, it just needs to look like an integration release. Gitlab doesn't sync
- deleted tags, so any subsequent manual trigger tags will need to increment the version number.
-
- 1. Delete the branch and tag, locally and on GitHub.
-
-- If a feature PR conflicting with the release PR is merged out of order.
-
- The following is a possible sequence of events that can result in the build pipeline failing:
-
- 1. A release PR is opened
- 2. A feature PR is opened and merged
- 3. The release PR is merged after the feature PR.
- 4. The release PR will not have updated and signed the feature PR's files, the released wheel will also not contain the changes from the feature PR.
-
- You may see an error like so:
-
- ```text
- in_toto.exceptions.RuleVerificationError: 'DISALLOW *' matched the following artifacts: ['/shared/integrations-core/datadog_checks_dev/datadog_checks/dev/tooling/commands/ci/setup.py']
- ```
-
- 1. Verify whether the hash signed in `.in-toto/tag.<KEYID>.link`, [(see example)](https://github.com/DataDog/integrations-core/blob/9836c71f15a0cb93c63c1d2950dcdc28b49479a7/.in-toto/tag.57ce2495.link) matches what's on `master` for the artifact in question.
-
- To see the hash for the artifact, run the following `shasum` command (replace local file path):
-
- ```
- shasum -a 256 datadog_checks_dev/datadog_checks/dev/tooling/commands/ci/setup.py
- ```
-
- 1. If any artifact mismatches, check out and pull the most recent version of the `master` branch.
-
- ```
- git checkout master
- git pull
- ```
-
- 1. Release the integration again with a new version, bump the version appropriately.
-
- ```
- ddev release make <INTEGRATION> --version <VERSION>
- ```
-
- 1. Verify that the integration files are signed, and update the integration changelog to reflect the feature PR title in the following format.
-
- ```
- * [<Changelog label>] <PR Title>. [See #<PR Number>](<Github PR link>).
- ```
-
- 1. After approval, merge PR to master for a new build to be triggered.
-
-
-## Releasers
-
-For whom it may concern, the following is a list of GPG public key fingerprints known to correspond to developers
-who, at the time of writing (27-09-2021), can trigger a build by signing [in-toto metadata](../meta/cd.md).
-
-??? info "[Christine Chen](https://api.github.com/users/ChristineTChen/gpg_keys)"
- - `57CE 2495 EA48 D456 B9C4 BA4F 66E8 2239 9141 D9D3`
- - `36C0 82E7 38C7 B4A1 E169 11C0 D633 59C4 875A 1A9A`
-
-??? info "[Paul Coignet](https://api.github.com/users/coignetp/gpg_keys)"
- - `024E 42FE 76AD F19F 5D57 7503 07E5 2EA3 88E4 08FD`
- - `1286 0553 D1DC 93A7 2CD1 6956 2D98 DCE7 FBFF C9C2`
-
-??? info "[Dave Coleman](https://api.github.com/users/dcoleman17/gpg_keys)"
- - `8278 C406 C1BB F1F2 DFBB 5AD6 0AE7 E246 4F8F D375`
- - `98A5 37CD CCA2 8DFF B35B 0551 5D50 0742 90F6 422F`
-
-??? info "[Greg Marabout Demazure](https://api.github.com/users/gmarabout/gpg_keys)"
- - `01CC 90D7 F047 93D4 30DF 9C7B 825B 84BD 1EE8 E57C`
- - `C719 8925 CAE5 11DE 7FC2 EB15 A9B3 5A96 7570 B459`
-
-??? info "[Paola Ducolin](https://api.github.com/users/pducolin/gpg_keys)"
- - `EAC5 F27E C6B1 A814 1222 1942 C4E1 549E 937E F5A2`
- - `A40A DD71 41EB C767 BBFB E0B8 9128 2E2F E536 C858`
-
-??? info "[Fanny Jiang](https://api.github.com/users/fanny-jiang/gpg_keys)"
- - `BB47 F8E8 8908 168B CAE4 324A D9C3 43B4 D73F BE12`
- - `800C 2BA9 A7AA 4F84 DD39 A558 4306 7845 F282 FB96`
-
-??? info "[Ofek Lev](https://api.github.com/users/ofek/gpg_keys)"
- - `C295 CF63 B355 DFEB 3316 02F7 F426 A944 35BE 6F99`
- - `D009 8861 8057 D2F4 D855 5A62 B472 442C B7D3 AF42`
-
-??? info "[Julia Simon](https://api.github.com/users/hithwen/gpg_keys)"
- - `0244 AAA8 DD1E FE47 30A4 F1CA 392C 882E 0DA0 C6C8`
- - `129A 26CF A726 3C85 98A6 94B0 8659 1366 CBA1 BF3C`
-
-??? info "[Florian Veaux](https://api.github.com/users/FlorianVeaux/gpg_keys)"
- - `3109 1C85 5D78 7789 93E5 0348 9BFE 5299 D02F 83E9`
- - `7A73 0C5E 48B0 6986 1045 CF8B 8B2D 16D6 5DE4 C95E`
-
-??? info "[Sarah Witt](https://api.github.com/users/sarah-witt/gpg_keys)"
- - `47C5 A022 73F1 CF81 04EE 8D1A 7A67 DC43 B24C 1542`
- - `0620 14C0 3FC0 44E5 F029 32A2 E50E CC57 6463 4BC1`
-
-??? info "[Alexandre Yang](https://api.github.com/users/AlexandreYang/gpg_keys)"
- - `FBC6 3AE0 9D0C A9B4 584C 9D7F 4291 A11A 36EA 52CD`
- - `F8D9 181D 9309 F8A4 957D 636A 27F8 F48B 18AE 91AA`
-
-??? info "[Andrew Zhang](https://api.github.com/users/yzhan289/gpg_keys)"
- - `EABC A4AC 14AC BAF0 06CC 0384 7C67 39CB 3A79 9F86`
- - `0149 2127 FC6E 1A4C 900B 78DA ED58 C98E BC9C C677`
diff --git a/mkdocs.yml b/mkdocs.yml
index 7a910bca5f156..648b6b5a29937 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -80,9 +80,6 @@ nav:
- Windows Event Log: architecture/win32_event_log.md
- Process:
- Integration release: process/integration-release.md
- - Agent release:
- - process/agent-release/pre-release.md
- - process/agent-release/post-release.md
- FAQ:
- FAQ: faq/faq.md
- Acknowledgements: faq/acknowledgements.md